Здравствуйте, Aikin, Вы писали:

A>Ага, до такого я как-то не додумался Но будет ли удобно работать с большим количеством маленьких вьюшек?
Будет, особенно при использовании графических библиотек, построенных на MVC — ведь там сделано аналогично, то есть будет проще накладывать MVC своего уровня приложения на MVC компонентного уровня.

A>Хотя где-то я уже читал про микровью и микроконтролееры (кажется один именитый архитектор ими просто бредил), отзывы о них были как-то не особо положительные.


A>Можно поинтересоваться, ты сам использовал такой подход?
Эм... а как можно использовать не самому?
Если вопрос в том, мое ли это гениальное изобретение, то ответ: нет, конечно же, содрал у других. Посмотрите какую-нибудь графическую библиотеку, построенную на MVC, к примеру, Swing/SWT. Так Table (таблица) — есть представление, состоящее из списка представлений TableItem (строка), каждый из которых представляет список представлений TableCell (ячейка).

A>Каковы впечателения от использования?
Благоприятные: волосы пока шелковистые, не седые — заказчикам нравится.

PS Если интересно, на сайте висит статья, где описывал, как можно еще сильнее упростить кодирование подобных представлений на основе обобщений.

R>Будет, особенно при использовании графических библиотек, построенных на MVC — ведь там сделано аналогично, то есть будет проще накладывать MVC своего уровня приложения на MVC компонентного уровня.
R>Посмотрите какую-нибудь графическую библиотеку, построенную на MVC, к примеру, Swing/SWT. Так Table (таблица) — есть представление, состоящее из списка представлений TableItem (строка), каждый из которых представляет список представлений TableCell (ячейка).
Ааа, вот ты о чем Я разбалованный дотнетчик у меня такие мини вьюшки (контролы) уже встроены в среду или как сторонние библиотеки. Поэтому я о них даже не думаю как о MVC, берешь и используешь
Меня интересует MVC/P создаваемое мною лично
A>>Можно поинтересоваться, ты сам использовал такой подход?
R>Эм... а как можно использовать не самому?
Ну книжек умных можно начитаться
A>>Каковы впечателения от использования?
R>Благоприятные: волосы пока шелковистые, не седые — заказчикам нравится.
Нет я про удобно-неудобно
R>PS Если интересно, на сайте висит статья, где описывал, как можно еще сильнее упростить кодирование подобных представлений на основе обобщений.
Сча поищем, спасибо.

IB>Ну, реальные приложения несколько сложнее, чем в примере и, как правило, они состоят из нескольких мало связаных частей. Реализация этих частей в виде самосотятельных MVC триад позволяет уменьшить между этими частями связность, повысить степень повторной используемости кода, легко реализовать расширяемость, ect... Вообщем классический набор.
IB>Например, очень удобно реализовывать различные плагинные конструкции, когда основное приложение реализует MVP, предоставляя каркас для модулей, которые, в свою очередь, реализуют MVP, размещая свои View в предоставленых основным приложением местах, при этом сами модули могут быть родительскими поотношению к модулям более низкого уровня... Или, уже озвученная ситуация, когда для большой красивой модели требуется несколько presenter-ов, в этом случае представляется разуным ввести некую метамодель и presenter более высокого уровня, для координации взаимодействия presenter-ов и состояния модели.

Так родился CAB здесь

Здравствуйте, rsn81, Вы писали:

эхх, раз уж отнекропостили ветку, тоже напишу

R>как начинающегося с накидывания визуальных форм а-ля Delphi и тянущегося за этим действием копания собственной могилы.

Что интересно, мы и в MVP пришли к такому сценарию создания троек.

1. Накидывается визуальная форма в дизайнере.
2. Глядя на нее, пишется интерфейс IView,
3. Пишется презентер по TDD, пока не будет реализован весь функционал и тесты не покажут веселые зелененькие кружочки
4. Возвращаемся к контролу view и реализуем интерфейс, пишем логику view.

2all — покритикуйте, расскажите как процесс происходит у вас.

R>Отметил следующие несомненные достоинства MVP по отношению к MVC:
+1

R>К недостатку MVP отнес бы следующее. Все же происходит повторение кода перекидывания данных из представления, но, насколько понял, именно за счет этого мы и получаем первое преимущество (см. выше). То есть, как мне кажется, это оправдывается с лихвой.

Не совсем понял, какой именно код повторяется. Скорее всего сказывается DateTime.Now.DayOfYear == 257

Добрый вечер!

Запутался Помогите разобраться со следующими вопросами:

1. Как соотносятся паттерн MVP и расслоение функциональности приложения?

Обычно, создавая веб-приложение, мы разбиваем его функционал на слои: ui, business logic, data access. Правильно ли будет считать, что view относится к слою пользовательского интерфейса, presenter — бизнес-логики, а model — "размазана" между бизнес-логикой (хранит состояние) и уровнем доступа к данным?

2. Как быть в случае, когда для выполнения действия presenter'у требуется взаимодействие с пользователем? Например, получить подтверждение на выполнение операции?

Варианты такие:

а) Presenter сам создает элементы пользовательского интерфейса. Например, диалог или MessageBox.
Не годится: presenter находится в business logic layer и, по хорошему, вообще не имеет ссылок на UI компоненты.

б) Presenter использует ухищрения вроде фабрик, чтобы создать диалоги или другие формы. По-моему, слишком тяжеловесно. Особенно если требуется всего-навсего отобразить MessageBox, чтобы узнать "да" или "нет".

в) Presenter дергает метод в интерфейсе представления. Например, IView.ConfirmCleanAll().

Склоняюсь к этому варианту. Хотя если представлений несколько, придется отслеживать, от какого пришел запрос presenter'у, так как только одно представление должно отобразить запрос на подтверждение операции.

3. В продолжение вопроса №2. Допустим, у нас ASP.NET приложение. Presenter не сможет выполнить UI код, не вернув управление. Т.е. код presenter'а нужно писать так, чтобы получив управление от View, он (неважно как) сделал запрос пользователя, после чего (очередной postback) продолжил дальнейшую работу. Фактически, реализация presenter'а зависит от технологии, а по-хорошему не должна.

Буду рад услышать комментарии...

Здравствуйте, Аноним, Вы писали:

А>Добрый вечер!

А>Запутался Помогите разобраться со следующими вопросами:

А>1. Как соотносятся паттерн MVP и расслоение функциональности приложения?
Никак.

А>Обычно, создавая веб-приложение, мы разбиваем его функционал на слои: ui, business logic, data access. Правильно ли будет считать, что view относится к слою пользовательского интерфейса, presenter — бизнес-логики, а model — "размазана" между бизнес-логикой (хранит состояние) и уровнем доступа к данным?
Иногда так бывает, но в общем случае так считать не правильно. Часто бывает что все детали MVP лежат в UI слое. Например, когда UI от BL отделены настолько, что не имеют общих классов модели.

А>2. Как быть в случае, когда для выполнения действия presenter'у требуется взаимодействие с пользователем? Например, получить подтверждение на выполнение операции?

А>Варианты такие:
A>...
А>в) Presenter дергает метод в интерфейсе представления. Например, IView.ConfirmCleanAll().

А>Склоняюсь к этому варианту. Хотя если представлений несколько, придется отслеживать, от какого пришел запрос presenter'у, так как только одно представление должно отобразить запрос на подтверждение операции.
Да, неплохой вариант.

А>3. В продолжение вопроса №2. Допустим, у нас ASP.NET приложение. Presenter не сможет выполнить UI код, не вернув управление. Т.е. код presenter'а нужно писать так, чтобы получив управление от View, он (неважно как) сделал запрос пользователя, после чего (очередной postback) продолжил дальнейшую работу. Фактически, реализация presenter'а зависит от технологии, а по-хорошему не должна.
В ASP.NET принято презентер хранить в состоянии вьюшки, тогда он может вести "диалог" с пользователем.
То что он зависит от технологий — не страшно. При необходимости универсального презентера Web/WinForms презентер должен будет удовлетворять обоим технологиям, но обычно универсальные презентеры не требуются.

Здравствуйте, <Аноним>, Вы писали:

А>Обычно, создавая веб-приложение, мы разбиваем его функционал на слои: ui, business logic, data access. Правильно ли будет считать, что view относится к слою пользовательского интерфейса, presenter — бизнес-логики, а model — "размазана" между бизнес-логикой (хранит состояние) и уровнем доступа к данным?
Вью и презентер всегда в UI (хотя сам UI может быть разделен на два слоя -- презентеры и вьюшки), модель может быть как объектом BL так и отдельной сущностью созданной специально для UI.
Презентер манипулирует бизнесс объектами (которые находятся в моделе) и классами доступа к данным чтобы решить свою задачу.


А>2. Как быть в случае, когда для выполнения действия presenter'у требуется взаимодействие с пользователем? Например, получить подтверждение на выполнение операции?
А>в) Presenter дергает метод в интерфейсе представления. Например, IView.ConfirmCleanAll().
+1
А>Хотя если представлений несколько, придется отслеживать, от какого пришел запрос presenter'у, так как только одно представление должно отобразить запрос на подтверждение операции.
Обычно делают один экземпляр презентера на один экземпляр вью. Либо вью передает себя как один из аргументов события (SomethingHappened(IView sender, e SomethingHappenedEventArgs)).
Я за первый вариант.

А>3. В продолжение вопроса №2. Допустим, у нас ASP.NET приложение. Presenter не сможет выполнить UI код, не вернув управление. Т.е. код presenter'а нужно писать так, чтобы получив управление от View, он (неважно как) сделал запрос пользователя, после чего (очередной postback) продолжил дальнейшую работу.
Для работы с пользователем у презентера есть только View и больше ничего. Не надо городить лишние связи.

А>Фактически, реализация presenter'а зависит от технологии, а по-хорошему не должна.
Ничего страшного в этом нет.

СУВ, Aikin