Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, rsn81, Вы писали: R>>Здравствуйте, IB, Вы писали: R>>Понятно. Чтобы говорить предметно, нужно все же ознакомиться с материалом. Ушел на поиски номера журнала. А>А когда он появиться в Питере??
Здравствуйте, swayf, Вы писали:
S>А когда он появиться в Мюнхене?
Ну, как закажешь, так и появится...
Вообще, с этими вопросами сюда: http://rsdn.ru/?forum/?group=mag
Здравствуйте, varely, Вы писали:
V>Дык написали уже — зарелизись они с месяц назад. Сейчас Hands-on лабы и версию под бейсик пишут вроде...
Ну, на сколько я знаю, CAB они пока не переписывали, хотя обещали.
V>Дык написали уже — зарелизись они с месяц назад. Сейчас Hands-on лабы и версию под бейсик пишут вроде...
Насколько я пинимаю вы имеете ввиду это
т.е. Smart Client Software Factory ?
Использовали где нибудь или может планы по использованию сего продукта есть?
Или может по крайней мере просто внимательно смотрели и чего то на основе его сделали тестового для себя?
Хочу просто услышать стороннее мнение, т.к. сейчас предстоит апгрейд с НЕТ 1.1 на 2.0 и по всей видимости переписывание
UI т.к. то что есть уже не соотвецтвует требованиям к нему..
Здравствуйте, Jericho113, Вы писали:
J>Здравствуйте, varely, Вы писали:
V>>Дык написали уже — зарелизись они с месяц назад. Сейчас Hands-on лабы и версию под бейсик пишут вроде...
J>Насколько я пинимаю вы имеете ввиду это J>т.е. Smart Client Software Factory ?
J>Использовали где нибудь или может планы по использованию сего продукта есть? J>Или может по крайней мере просто внимательно смотрели и чего то на основе его сделали тестового для себя? J>Хочу просто услышать стороннее мнение, т.к. сейчас предстоит апгрейд с НЕТ 1.1 на 2.0 и по всей видимости переписывание J>UI т.к. то что есть уже не соотвецтвует требованиям к нему..
Непосредственно Software Factory не использовал (ибо когда начали проект его еще небыло), использовал CAB. Что хочу сказать
1. почиму начали вобще использовать CAB: в свое время написан был проект в котором была реализована схожая система (по крайней мере для событий) и чтото типа WorkItem'ов естественно сразу когда я увидел CAB возникло желание его использовать. Скажу прямо он действительно неплохо работает и реально помогает.
2. счас есть достаточно большой проект (7 Мб исходников на С#) GUI с использованием CAB в основном у нас возникали проблемы в ситуациях когда одни и тотже контрол показываетс в 2х разных местах, возникают всякие проблемы с командами особенно (ну и с сообщениями тоже).
3. смотрел Smart Client Software Factory вобщемто всеравно он весь строится на CAB за небольшими отличиями, это я к тому что все что относится к CAB (на данный момент) отнорсится и к SCSF
Re[2]: странно, а почему не упомянули статьи на codeproject
Здравствуйте, Jericho113, Вы писали:
J>Здравствуйте, varely, Вы писали:
Писал небольшой проект (15 вьюшек), используя CAB напрямую + свои workspaces.
Встречались небольшие баги именно при наследовании workspace.
Основное, что не понравилось — дикие тормоза при загрузке/открытии форм, ибо все
создание объектов происходит через рефлекшн. Особенно если использовать контролы,
насыщеные графикой (DevExpress в частности) — форма грузится 1.5-2 сек на AthlonXP 1700+ 256Mb RAM
Re[3]: Model-View-Controller в .Net
От:
Аноним
Дата:
14.08.06 06:04
Оценка:
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, <Аноним>, Вы писали:
А>>так и знал что минусов наставят и оценка низкая будет IB>Меня другое интересует, за что минусы — за статью или за аннотацию?..
Здравствуйте, <Аноним>, Вы писали:
IB>>Меня другое интересует, за что минусы — за статью или за аннотацию?.. А>За то что статья в оффлайне.
Просто убийственный аргумент!
Здравствуйте, <Аноним>, Вы писали:
А>За то что статья в оффлайне.
Ну а статья-то тут причем, такова политика журнала и сайта...
В любом случае, через несколько месяцев статья появится в открытом доступе.
У меня есть несколько вопросов по model-view separation.
Сначала опишу что и как я понимаю по содержанию статьи:
Для чего нужен view: для отображения пользователю каких-либо данных из модели, а также для ввода от пользователя каких-либо значений или получения команд. В слой представления входят элементы, неодходимые для обеспечения этих задач: всевозможные контролы для вин и веб приложений; для интерфейса командной строки – вывод и ввод текста .
Код, реализующий логику работы приложения, конечно, лучше отделить от кода рисования гуи и т.п. – это позволит достаточно свободно менять представления, не затрагивая объекты модели (сменить вин-представление на веб или на командную строку, напр.). Под логикой работы приложения здесь имею ввиду ту функциональность, которая обеспечивается приложением (для решения пользовательских задач) и описывается в его функциональной спецификации – use case’ах. Для этой функциональности все равно, каким образом пользователь ввел, напр. температуру в градусах по Цельсию (см. пример из статьи) – через вин или веб контрол или с командной строки – важно что он ввел. Т.е. слой представления для реализации данной функциональности Должен реализовать возможность ввода этого значения. Данное семантическое требование явным образом выражается синтаксически через реализацию формой (class FormView : Form, IView) интерфейса IView, в котором, собственно, и описывается это требование как контракт.
Очевидно, что в данном случае функциональность приложения значительно лучше покрывыется юнит тестами – реализуешь свой класс «представления», наследуя его от IView, в нем эмулируешь работу пользователя и смотришь что из этого получается...
Presenter, в свою очередь, и есть тот слой, который отвечает за логику работы приложения и реализацию его функциональности через использование экземпляра класса преставления, реализующего этот интерфейс, а также вызывая методы объектов Модели (если я правильно ошибаюсь).
Вот у меня некоторая терминологическая размытость образовалась.. Занимаюсь этими вопросами недавно – читаю, размышляю и т.п.
Например, как понятия MVC, MVP соотносятся с с понятиями Use-Case Controller, Session Controller, Application Layer или фасадом модели предметной области?
Можно ли под MVP понимать Use-Case Controller или Session Controller? Или Use-Case Controller – один из вариантов MVP. Или может это совсем разные вещи? MVP как обращается к объектам модели – напрямую или через фасад/контроллер в роли которого может выступить Use-Case Controller или Session Controller?
Допустим у нас есть некоторый прецедент «Оформить покупку», который включает другой прецедент «Произвести аутентификацию». Причем сначала пользователю нужно аутентифицироваться, а потом производить дальнейшие действия. Где и как это ограничение кодировать? Можно положится на уровень представления – закодировать его так, что сначала выводится форма ввода логина/пароля а затем, если они правильные, выдавать форму оформления покупки. Или лучше это сделать в контроллере прецедента? Тогда в нем будет реализация State Machine, и каждый открытый метод контроллера должен начинаться с проверки текущего состояния прецедента и, в зависимости от этого, либо продолжать выполнение, либо кидаться исключением.
Еще вопрос: если контент формы FormView разнести на две разные формы (в одной вводятся значения по фаренгейту, в другой – по цельсию), нужно ли интерфейс IView и класс Presenter также делить на две части? Т.е. необходимо ли делать так, чтобы каждому Presenter’у соответствовал один IView, насладники которого полностью реализуют все его операции. Иначе получится не очень красиво, если часть «реализуемых» методов делать пустыми “{}”. Кроме того, классу Presenter нужно будет работать не с одним view, а с множеством.
Если Presenter работает со множеством View, то, думаю, можно для каждого прецедента сосдать свой IView, в котором объявляются все методы и т.д., которые могут понадобиться для данного прецедента. Тогда Presenter можно будет приблизить к тому, чтобы он стал контроллером прецедента. Правда, придется во всех формах-наследниках этого IView большинство методов сделать пустыми “{}”, что имхо отвратительно
Можно наоборот, максимально раздробить на разные интерфейсы все то, что содержалость в одном IView. Причем дробить по принципу height cohesion – в каждом интерфейсе содержаться ф-ии и т.п. на столько связанные, что заведомо они будут использоваться совместно:
void SetFarenheit(double value);
event EventHandler<EventArgs> SetFarenheit;
Тогда конкретная форма будет реализовывать множество интерфейсов IView и вместо конструктора презентера «public Presenter(IView view)» нужно будет делать кучу методов регистрации различных представлений в одном презентере (регистрацию вроде лучше поручить самим классам представлений)...
А>а также для ввода от пользователя каких-либо значений или получения команд.
В оригинале за ввод отвечает контроллер, но в MVP таки да, все все равно проходит через View.
А>Вот у меня некоторая терминологическая размытость образовалась.. Занимаюсь этими вопросами недавно – читаю, размышляю и т.п. А>Например, как понятия MVC, MVP соотносятся с с понятиями Use-Case Controller, Session Controller, Application Layer или фасадом модели предметной области? А>Можно ли под MVP понимать Use-Case Controller или Session Controller? Или Use-Case Controller – один из вариантов MVP. Или может это совсем разные вещи?
Если говорить об MVC, то Session Controller или Use-Case Controller — это лишь один из возможных типов Controller-а (Presenter-а), то есть не всей триады, а лишь одной из ее частей. Какой из вариантов контроллера применить — зависит от конкретной задачи. Application Layer — это слой приложения отвечающий за бизнес-логику, в случае MVC/P — это все что не входит во View, хотя в некоторых случаях под этим понимается исключительно модель/и. Фасад модели предметной области — так же зависит от типа приложения и применяемого паттерна, в случае MVC это, как правило, самостоятельная сущность (Медиатор), которая является посредником между контроллером и нижележащей моделью. В случае же MVP эту обязанность берет на себя Presenter.
А> MVP как обращается к объектам модели – напрямую или через фасад/контроллер в роли которого может выступить Use-Case Controller или Session Controller?
См. предыдущий ответ. Presenter и есть Session или Use-Case контроллер, если, конечно используется такой тип Presenter-а, поэтому здесь по определению никакого посредника нет. Если же реализуется "классический" MVC, то как правило между Controller-ом (Session, Use-Case, Facade или каким-то другим) есть еще некий медиатор, который и общается с моделями.
А>Допустим у нас есть некоторый прецедент «Оформить покупку», который включает другой прецедент «Произвести аутентификацию». Причем сначала пользователю нужно аутентифицироваться, а потом производить дальнейшие действия.
Это не входит в зону ответственности данного паттерна, он лишь помогает разделить части системы, а уж что в вашем приложении к какой части системы относится, вопросво многих случаях однозначного ответа не имеющий. Однако в случае аутентификации основные проверки всегда должны быть на уровне бизнес-логики, а во view толко дубляж для удобства пользователя.
А>Еще вопрос: если контент формы FormView разнести на две разные формы <...> А>(в одной вводятся значения по фаренгейту, в другой – по цельсию), нужно ли интерфейс IView и класс Presenter также делить на две части?<..>
Зависит от, как в конкретном случае удобнее, так и надо делать. Это уже особенность конкретного приложения а не свойство паттерна. Например известны реализации, когда каждый отдельно взятый контрол представляет собой триаду MVP. Или еще более сложный случай — помимо того, что каждый отдельный контрол MVP, набор таких контролов реализует подсистему, которая тоже MVP и View этой подсистемы как раз и содержит эти контролы, а подсистема, в свою очередь, является частью VP основного приложения. При этом иерархия может быть и выше и варианты реализации разные, со связью через View/Presenter или только через Presenter — см. паттерны Hierarchical Model-View-Controller (HMVC) и Presentation-Abstraction-Control (PAC).
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re: Screencast на эту же тему
От:
Аноним
Дата:
26.10.06 21:19
Оценка:
Это интересно, как раз неделю назад я закончил screencast для программистов из нашей компании. А тут -- эта статья. Грех не поделиться своими идеями и наработками, благо они были изрядно опробованны в последний год.
Краткое содержание
1. Проблемы, возникающие при разработке страниц/контролов на ASP.NET
2. Краткое описание паттерна MVC
3. Вариант реализации паттерна в среде ASP.NET (с примером)
Known bugs
* На слайде с ответственностями контроллер назван "представлением"
* Нигде нет информации, что рядом с презентацией лежат исходники примера, который использован в презентации и сама презентация :-)
Здравствуйте, dotnetcoder, Вы писали:
D>примера в Session
а если Session обернуть SessionProvider и при инстанцировании Presenter передавать WebSessionProvider, который будет оберткой над Session? D>Я когда свою FSM писал, переполз на листнеры и хэндлеры на основе интерфейсов.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, dotnetcoder, Вы писали: C>а если Session обернуть SessionProvider и при инстанцировании Presenter передавать WebSessionProvider, который будет оберткой над Session?
И что это даст ? В Session всёравно нельзя положит пока Presenter имеет ссылки на MarshalByRef (View) и без атрибута [Serializible] при SessionState=Server
Здравствуйте, dotnetcoder, Вы писали:
D>Осмелюсь сказать что этот несчастный пример из статьи негоден для ASP.NET,
Годен-годен, другое дело что не совсем таком виде, но концепция в целом такая.
D> а уже тем более если SessionState=Server
Ну, яж нигде не утверждал, что такой подход годится для всех типов ASP.Net приложений.. Для поддержки сессий вполне подходит паттерн SessionProvider, как совершенно справедливо замечено в соседнем сообщении. У ASP.Net есть и другие особенности, можно вспомнить тот же Post Back, который так же надо учитывать... Но цель статьи, как я уже писал, была не предоставить готовое приложение или описать особенности использования MVP в ASP.Net, а показать саму идею паттерна и его возможности по смене представлений. Если писать приложение по всем правилам, то сам паттерн замажется, а хотелось его-то в первую очередь и показать.
D>Для ASP.NET писать app контроллер (ok, presenter надо используя интерфейсы а не events. Попытайтесь засунуть Presenter из D>примера в Session
А зачем? Presenter от состояния не зависит, состояние важно для модели.
D>Я когда свою FSM писал, переполз на листнеры и хэндлеры на основе интерфейсов.
Да байта ради, это-то как раз не принципиально... =)
D>И кстати, а как вы реализуете вызов WebService'а в ASP.NET который возвращает данные ?
Бррр.. Как из asp.net вызвать webServcie или как в эту архитектуру вписывается реализация webService?
Здравствуйте, dotnetcoder, Вы писали:
D>И что это даст ? В Session всёравно нельзя положит пока Presenter имеет ссылки на MarshalByRef (View) и без атрибута [Serializible] при SessionState=Server
А зачем Presenter в сессию класть? Во-первых это просто по логике Stateless класс, а во-вторых, даже если в каком-то конкретном случае это окажется не так, то есть паттерн memento, с помощю которого можно вынести состояние в отделную сущность и хранить его спокойно где надо.
Мы уже победили, просто это еще не так заметно...
надо используя интерфейсы а не events. Попытайтесь засунуть Presenter из
