Статья:
Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

Авторы:
Иван Бодягин

Аннотация:
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и в месте с ними изменялся и сам паттерн. Данная статья посвящена так же одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, перимуществам и недостаткам, а так же описанию сопутствующих паттернов.

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

ИБ>Авторы:
ИБ> Иван Бодягин

ИБ>Аннотация:
ИБ>В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и в месте с ними изменялся и сам паттерн. Данная статья посвящена так же одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, перимуществам и недостаткам, а так же описанию сопутствующих паттернов.

Дело описывать такие паттерны дело не благодарное (так и знал что минусов наставят и оценка низкая будет)

Хотя спасибо за попытку

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

А>так и знал что минусов наставят и оценка низкая будет
Меня другое интересует, за что минусы — за статью или за аннотацию?..

А>Хотя спасибо за попытку
Да пожалуйста... Вообще статья планиировалась несколько болше с разбором более сложных случаев, иерархических версий паттерна, ect., но поджимали сроки, последние правки вбивались практически перед отправкой номера в печать..

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

Демонстрационный проект к статье лежит здесь: http://files.rsdn.ru/343/DegreeConverter.rar

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

ИБ>>Статья:
ИБ>>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

IB>Демонстрационный проект к статье лежит здесь: http://files.rsdn.ru/343/DegreeConverter.rar

все просто и красиво выглядит как MVP

Немного критики:
1) ну кто же модель создает в Presenter. Вообще есть идея хранить модель либо в сессии либо в БД в зависимости от типов данных (имеется ввиду по предназначению а не типы int, string )

2) Не обрабатывается во View ситуация когда ничего не вводят — FormatException

3) Где евенты на изменения свойств или предполагается использовать binding?

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

А>Немного критики:
Ответ на все простой... Цель данного приложения не предоставить полнофункциональное приложение, готовое к использованию, а проиллюстрировать идею паттерна на максимально простом и прозрачном коде..
Если все делать совсем по правильному, то и View создаются через фабрику, и экземпляры моделей Presenter получает через тот же Dependency Injection или вообще Service Locator (хотя для простых случаев можно и как в примере) и полноценная обработка ошибок нужна, ect... Но весь этот дополнительный код замажет сам паттерн, а именно его и хотелось продемонстрировать в первую очередь.

A>Где евенты на изменения свойств или предполагается использовать binding?
Изменения свойств модели? Там event-ов быть не должно, это объясняется в статье...

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

IB>Ответ на все простой... Цель данного приложения не предоставить полнофункциональное приложение, готовое к использованию, а проиллюстрировать идею паттерна на максимально простом и прозрачном коде..

эта задача решена

IB>Если все делать совсем по правильному, то и View создаются через фабрику, и экземпляры моделей Presenter получает через тот же Dependency Injection или вообще Service Locator (хотя для простых случаев можно и как в примере) и полноценная обработка ошибок нужна, ect...

Во!!! — то что надо. Хлеба и зрелищ. Аффтар Жжот Писши Исчо

IB>Но весь этот дополнительный код замажет сам паттерн, а именно его и хотелось продемонстрировать в первую очередь.

Думаю стоит переработать метод изложения в этом случае.

IB>Изменения свойств модели? Там event-ов быть не должно, это объясняется в статье...

А как быть если у меня две пары view/presenter и одна model?
Хитро получается — придется делать как гласит КОП (в форуме философии) для модели

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

А>Думаю стоит переработать метод изложения в этом случае.
Тогда это была бы совсем другая статья, про совсем другой паттерн..

А>А как быть если у меня две пары view/presenter и одна model?
Например, ввести общий Presenter уровнем выше или организовать взаимодействие Presenter-ов друг с другом через Observer...
Да и отсутствие событий в модели — не жесткое условие, просто рекомендация, вполне разумная на мой взгляд. Все зависит от конкретной ситуации.

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

IB>Да и отсутствие событий в модели — не жесткое условие, просто рекомендация, вполне разумная на мой взгляд. Все зависит от конкретной ситуации.
Объясните, пожалуйста, требование отсутствия событий в модели. Пока не имею возможности ознакомиться со статьей, но обязательно прочту в скором времени.

IB>Например, ввести общий Presenter уровнем выше или организовать взаимодействие Presenter-ов друг с другом через Observer...
К чему такие сложности? Мне кажется правомерным замечание о двух View, которые должны получать события от одной и той же Model. Сам именно так всегда и проектировал.

Достаточно важным кажется следующий момент. Первый проект с внедрением шаблона MVC писал на Java версии 1.5, а потому сразу проектировал ядро MVC с использованием Generic — тогда еще новинкой. Аналогично сейчас переписываю ядро на Microsoft Framework .Net 2. Использование типизации классов ядра MVC значительно упрощает дальнейшую разработку на его основе.

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

R>Объясните, пожалуйста, требование отсутствия событий в модели. Пока не имею возможности ознакомиться со статьей, но обязательно прочту в скором времени.
Это не требование, это рекомендация. Обоснована она тем, что часть функционала, который в классическом MVC лежит на модели, в MVP переведен в Presenter, а так же целями, которые стоят при реализации View — в статье об этом сказано более подробно.

R>К чему такие сложности?
Наличие оповещения View Моделью, устанавливает сильную зависимость View от модели и вообще усложняет View, чего хотелось бы избежать, а в некотрых случаях с оповещением вообще может быть бедулька, например, если одним из View является web-приложение. Впрочем, все зависит от ситуации, повторюсь, это всего лишь рекомендация. И об этом опять-таки сказано в статье..

R> Мне кажется правомерным замечание о двух View, которые должны получать события от одной и той же Model.
Несколько View, как правило, обслуживаются одним Presenter-ом, View меняется гораздо чаще чем Presenter.

R> Использование типизации классов ядра MVC значительно упрощает дальнейшую разработку на его основе.
Ну, это уже ортогональный аспект, все зависит от конкретной задачи, иногда действительно удобно использовать подобную параметризацию, но на суть паттерна это не влияет.

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

Понятно. Чтобы говорить предметно, нужно все же ознакомиться с материалом. Ушел на поиски номера журнала.

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

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

R>Понятно. Чтобы говорить предметно, нужно все же ознакомиться с материалом. Ушел на поиски номера журнала.

А когда он появиться в Питере??

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

Прочитал статью, посмотрел примеры.
Интересное исследование, хочу поблагодарить автора.

Классический шаблон MVC описан на удивление доходчиво. На удивление — это ирония отнюдь не в сторону способностей автора доходчиво доносить свои мысли читателю, а в сторону относительной сложности объяснения необходимости использования шаблона MVC достаточно большой кагорте программистов, которые не знают другого подхода к программированию, как начинающегося с накидывания визуальных форм а-ля Delphi и тянущегося за этим действием копания собственной могилы.

Сам проектирую desktop (Java, C#) и web-системы (C# ASP.NET) на основе именно классического шаблона MVC. Потому модификация шаблона MVP не могла не заинтересовать.

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

1. Представление получается легким, что скорее всего действительно позволит покрыть тестами большую область проекта и в большей мере избавиться от тестирования и отладки визуальных объектов, чем в MVC. Там это действительно головная боль.

2. Взаимодействие в системе MVP получается более простым, чем в MVC, где имеет место замкнутое кольцо: при активном действии пользователя, к примеру, представление дергает контроллер, который изменяет модель соответствующим образом, модель в свою очередь генерирует событие о своем изменении, которое принимает представление. Событийная модель MVC, как мне кажется, относительна сложна в плане понимания, то есть при разрастании проекта на основе MVC может наступить момент, когда программист запутается во взаимосвязях. Но, в принципе, вероятность этого можно свести к минимуму, решение есть...

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

Если автор найдет время, интересно было бы прочитать его комментарии по поводу вышесказанного (возможно, что-то из материала понял неверно) и по поводу проектирования иерархической MVC — хотя бы в двух словах: область применения, преимущества и т.п.

(c) В соавторстве с arts80.

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

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

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

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

К сожалению не имею возможности ознакомится со статьей, давно изучаю (и использую) МВП и убедился в его ценности, но всеже есть несколько вопросов:
1. Как всетаки писать юнит тесты, тоесть интересует сама технология что сначла реализовывать реальную форму а потом тесты, или наоборот, может одновременно. и как в будущем удерживать форму и тесты в синхронном сосотоянии (тоесть быть увереным что по крайней мере большая чать функционала формы и контролера охвачены тестами).
2. использую CAB как фреймворк. может есть у кого какието отзывы по работе с ним (тоесть что лучше делать, что нет)
3. до сих пор не могу толком определится с процессом создания ново формы, кто и как ее должен создавать (думается что не контроллер), и как этот момент пестировать

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

B>1. Как всетаки писать юнит тесты, тоесть интересует сама технология что сначла реализовывать реальную форму а потом тесты, или наоборот, может одновременно. и как в будущем удерживать форму и тесты в синхронном сосотоянии (тоесть быть увереным что по крайней мере большая чать функционала формы и контролера охвачены тестами).
Ну это вопрос скорее к относится к идеологии TDD, нежели к архитектуре паттерна. Вообще маньяки от TDD настаивают на том, что прежде всего пишется тест, а потом уже сам тестируемый метод. На данную тему есть статья Питера Провоста (Peter Provost) Test-Driven Development in .NET. Там как раз на примере MVP разбираются принципы разработки через тестирование.
К слову, Провост один из основных разработчиков CAB.

B>2. использую CAB как фреймворк. может есть у кого какието отзывы по работе с ним (тоесть что лучше делать, что нет)
Отзывы очень простые — не использовать CAB.. На самом деле использовать конечно, сам по себе он довольно толковый, имеется ввиду — не использовать его в разработке в чистом виде, он просто для этого не предназначен. Это не готовая библиотека, это просто иллюстрация архитектурного подхода. Надо либо брать CAB как он есть и затачивать под свою задачу, либо класть его рядом и реализовывать что-то свое на его основе, выдирая оттуда куски кода.

B>3. до сих пор не могу толком определится с процессом создания ново формы, кто и как ее должен создавать (думается что не контроллер), и как этот момент пестировать
Обычно такими вещами занимается специальная фабрика или же сам контроллер/Presenter является фабрикой для представлений, об этом есть упоминание в статье.

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

ИБ>Авторы:
ИБ> Иван Бодягин

В дополнение к теме. В блоге Phillip J Haack на днях появилась почти статья:
ASP.NET Supervising Controller (Model View Presenter) From Schematic To Unit Tests to Code и буквально вчера Tying MVP To the ASP.NET Event Model

Рекомендую

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

B>>1. Как всетаки писать юнит тесты, тоесть интересует сама технология что сначла реализовывать реальную форму а потом тесты, или наоборот, может одновременно. и как в будущем удерживать форму и тесты в синхронном сосотоянии (тоесть быть увереным что по крайней мере большая чать функционала формы и контролера охвачены тестами).
IB>Ну это вопрос скорее к относится к идеологии TDD, нежели к архитектуре паттерна. Вообще маньяки от TDD настаивают на том, что прежде всего пишется тест, а потом уже сам тестируемый метод. На данную тему есть статья Питера Провоста (Peter Provost) Test-Driven Development in .NET. Там как раз на примере MVP разбираются принципы разработки через тестирование.
IB>К слову, Провост один из основных разработчиков CAB.

благодарю за ссылку, но читал раньше.
это я к тому, что если формочка не с 2мя кнопками и едит боксом, а например контрол плана грида в OutLook (со всеми контекстными меню и тп) то мне кажется что вот так вслепую написать мок для такого контрола далеко не каждый сможет. и вобще какая гарантия что мок и реальный контрол работаю единым образом (тоесть ситуации типа тесты проходят, но реально ниче не пашет), меня тут интересует очень именно опыт а не теория. ну из теории конечно как избежать подобных вещей.

B>>2. использую CAB как фреймворк. может есть у кого какието отзывы по работе с ним (тоесть что лучше делать, что нет)
IB>Отзывы очень простые — не использовать CAB.. На самом деле использовать конечно, сам по себе он довольно толковый, имеется ввиду — не использовать его в разработке в чистом виде, он просто для этого не предназначен. Это не готовая библиотека, это просто иллюстрация архитектурного подхода. Надо либо брать CAB как он есть и затачивать под свою задачу, либо класть его рядом и реализовывать что-то свое на его основе, выдирая оттуда куски кода.

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

B>>3. до сих пор не могу толком определится с процессом создания ново формы, кто и как ее должен создавать (думается что не контроллер), и как этот момент пестировать
IB>Обычно такими вещами занимается специальная фабрика или же сам контроллер/Presenter является фабрикой для представлений, об этом есть упоминание в статье.

как я говорил статью к сожалению почитать немогу, хотелось бы попытаться разобраться тут подробнее.

заранее благодарю.

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

B> и вобще какая гарантия что мок и реальный контрол работаю единым образом (тоесть ситуации типа тесты проходят, но реально ниче не пашет), меня тут интересует очень именно опыт а не теория. ну из теории конечно как избежать подобных вещей.
Я не являюсь активным сторонником TDD, поэтому не могу поделиться богатым практическим опытом по данному вопросу.
Однако, в данной ситуации можно утверждать следующее.. Наличие интерфейса позволяет гарантировать, что класс, который взаимодействует с мок-объектом, никак не зависит от внутренней реализации мока или реального объекта, который будет вместо мока. А значит, если мок проходит а реальный объект не работает, то либо мок покрывает не все возможные сценарии взаимодействия через вышеозначенный интерфейс, либо проблемы с реальным объектом. Второй случай уже выходит за рамки ответственности данного теста, а первый лежит целиком на разработчике мок-объекта...

B>я уже несколько раз встречал подобное мнение, но не видел не одного аргумента почиму не использовать.
Ну, на мой взгляд, мнение авторов уже достаточный аргумент, когда мы разговаривали с тем же Питером и Eugeneo Pace (прям не знаю как его имя правильно по русски транскрибировать... ), они говорили именно о таком использовании, как я описал. Ну и по здравому размышлению, там просто очень много чего не реализовано, что должно быть в полноценной библиотеке, и углы местами срезаны. Вообщем — использовать безусловно можно, но он определенно тербует доводки руками.
Для готового использования эта же команда пишет SC-BAT (SmartClient BaseLine Architecture Toolkit — если мне никто не изменяет). Вот это уже будет готовая полноценная библиотека, куда и войдет, помимо всего прочего, отрихтованый и вылизаный CAB.

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

IB>Для готового использования эта же команда пишет SC-BAT (SmartClient BaseLine Architecture Toolkit — если мне никто не изменяет). Вот это уже будет готовая полноценная библиотека, куда и войдет, помимо всего прочего, отрихтованый и вылизаный CAB.

Дык написали уже — зарелизись они с месяц назад. Сейчас Hands-on лабы и версию под бейсик пишут вроде...

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

А>Здравствуйте, rsn81, Вы писали:
R>>Здравствуйте, IB, Вы писали:
R>>Понятно. Чтобы говорить предметно, нужно все же ознакомиться с материалом. Ушел на поиски номера журнала.
А>А когда он появиться в Питере??

А когда он появиться в Мюнхене?

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

S>А когда он появиться в Мюнхене?
Ну, как закажешь, так и появится...
Вообще, с этими вопросами сюда: http://rsdn.ru/?forum/?group=mag

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

V>Дык написали уже — зарелизись они с месяц назад. Сейчас Hands-on лабы и версию под бейсик пишут вроде...
Ну, на сколько я знаю, CAB они пока не переписывали, хотя обещали.

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


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

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

там вначале еще ссылка на not-advanced :)

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

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

Писал небольшой проект (15 вьюшек), используя CAB напрямую + свои workspaces.
Встречались небольшие баги именно при наследовании workspace.
Основное, что не понравилось — дикие тормоза при загрузке/открытии форм, ибо все
создание объектов происходит через рефлекшн. Особенно если использовать контролы,
насыщеные графикой (DevExpress в частности) — форма грузится 1.5-2 сек на AthlonXP 1700+ 256Mb RAM

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

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

А>>так и знал что минусов наставят и оценка низкая будет
IB>Меня другое интересует, за что минусы — за статью или за аннотацию?..

За то что статья в оффлайне.

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

IB>>Меня другое интересует, за что минусы — за статью или за аннотацию?..
А>За то что статья в оффлайне.
Просто убийственный аргумент!

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

А>За то что статья в оффлайне.
Ну а статья-то тут причем, такова политика журнала и сайта...
В любом случае, через несколько месяцев статья появится в открытом доступе.

Не по существу статьи...
В тексте встретилась очепятка "задачь"
Может стоит исправить?

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

ИБ>Авторы:
ИБ> Иван Бодягин

У меня есть несколько вопросов по 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).

Это интересно, как раз неделю назад я закончил screencast для программистов из нашей компании. А тут -- эта статья. Грех не поделиться своими идеями и наработками, благо они были изрядно опробованны в последний год.

Краткое содержание
1. Проблемы, возникающие при разработке страниц/контролов на ASP.NET
2. Краткое описание паттерна MVC
3. Вариант реализации паттерна в среде ASP.NET (с примером)

Known bugs
* На слайде с ответственностями контроллер назван "представлением"
* Нигде нет информации, что рядом с презентацией лежат исходники примера, который использован в презентации и сама презентация :-)

Итак, скачать:

Screencast: http://enox.pp.ru/articles/MVCinASPNET/MVC%20in%20ASPNET.swf (осторожно, ~20Mb)
Презентация: http://enox.pp.ru/articles/MVCinASPNET/MVCinASP.ppt
Исходники примера: http://enox.pp.ru/articles/MVCinASPNET/Demo.zip

Обсуждать, критиковать и предлагать идеи прошу у меня в ЖЖ (http://enox.livejournal.com/638817.html?mode=reply)

либо непосредственно в почте: yurys-at-rapidsoft.ru

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

Осмелюсь сказать что этот несчастный пример из статьи негоден для ASP.NET, а уже тем более если SessionState=Server

Для ASP.NET писать app контроллер (ok, presenter надо используя интерфейсы а не events. Попытайтесь засунуть Presenter из
примера в Session

Я когда свою FSM писал, переполз на листнеры и хэндлеры на основе интерфейсов.

И кстати, а как вы реализуете вызов WebService'а в ASP.NET который возвращает данные ?

Мне пришлось расширять (partial class) WebServiceProxy интерфейсом (IService например). Фабрикой возвращяю IService создавая WebServiceProxy ad-hoc.

Есть ещё варианты ?

Здравствуйте, 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, с помощю которого можно вынести состояние в отделную сущность и хранить его спокойно где надо.

Довольно много орфографических ошибок для статьи напечатанной на бумаге и продаваемой за деньги.

и в месте с ними

посвящена так же

с чьей либо

помощю

в следствии чего

из вне
...

Не о говоря уж о совершенно произвольной пунктуации и спряжениях.

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

IB>А зачем Presenter в сессию класть? Во-первых это просто по логике Stateless класс, а во-вторых, даже если в каком-то конкретном случае это окажется не так, то есть паттерн memento, с помощю которого можно вынести состояние в отделную сущность и хранить его спокойно где надо.
Ага. В ASP.NET 2.0 есть готовое решение — ViewState, сохранение состояния. А, к примеру, в Eclipse, точнее в jface, есть также готовое решение, которое называется одноименно с шаблоном проектирования — интерфейс IMemento и поддержка его со стороны визуальных форм.

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

IB> Но цель статьи, как я уже писал, была не предоставить готовое приложение или описать особенности использования MVP в ASP.Net, а показать саму идею паттерна и его возможности по смене представлений. Если писать приложение по всем правилам, то сам паттерн замажется, а хотелось его-то в первую очередь и показать.
И действительно, MVC/MVP в любом случае всего лишь каркас... точнее даже часть каркаса приложения. Смысла приводить полное описание готового решения на все случаи жизни нет. Во-первых, сложно будет разобраться, во-вторых, как и отметил IB, сущность каркаса MVC будет донельзя размыта, разнесена по другим не менее важным каркасным сущностям приложения. К примеру, DAL, попробуйте привести описание частной реализации скрещивания MVC и DAL — все... пиши-пропало.

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

E>Довольно много орфографических ошибок для статьи напечатанной на бумаге и продаваемой за деньги.
Это наверно претензии не к автору, а к редакторам? Вроде бы раздел есть соответствующий... по журналу.

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

R>Ага. В ASP.NET 2.0 есть готовое решение — ViewState, сохранение состояния.

... на клиенте. Вот вы тут все вумными словами кидаетесь, прошу, покажите мне реализацию (code) хоть Memento хоть SessionProvider хоть ViewState применительно к ASP.NET когда SessionState=Server

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

D>... на клиенте. Вот вы тут все вумными словами кидаетесь, прошу, покажите мне реализацию (code) хоть Memento хоть SessionProvider хоть ViewState применительно к ASP.NET когда SessionState=Server
Прошу прощения, но не понял просьбы. Как бы какая-то "закавыка" в просьбе присутствует, вот только не пойму, в чем она?
Если серьезно, то пример кода в документации несложно найти.

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

D> Вот вы тут все вумными словами кидаетесь, прошу, покажите мне реализацию (code) хоть Memento хоть SessionProvider хоть ViewState применительно к ASP.NET когда SessionState=Server

Memento: http://dofactory.com/Patterns/PatternMemento.aspx
На словах, суть паттерна проста как рельс — если надо как-то сохранить внутреннее состояние объекта, не трогая сам объект, то надо создать новую сущность, которая будет хранить это состояние и объект должен уметь свое состояние сохранить в эту сущность и восстановиться из нее.

ServiceProvider — по сути универсальный интерфейс для хранилища состояний, будь-то сессия, ViewState, куки, watever... Иными словами хранилище memento-объектов, реализация которого зависит от ситуации, нужд разработчика и цены огурцов на стамбульском базаре в прошлый четверг — не суть.

Далее все просто. Presenter берет в одну руку какую-то реализацию ISessionProvider, в другую memento объект с состоянием, и либо сохраняет одно в другом, либо восстанавливает объект из хранилища, смотря что системе нужно в данный момент.

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

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

D>>... на клиенте. Вот вы тут все вумными словами кидаетесь, прошу, покажите мне реализацию (code) хоть Memento хоть SessionProvider хоть ViewState применительно к ASP.NET когда SessionState=Server
R>Прошу прощения, но не понял просьбы. Как бы какая-то "закавыка" в просьбе присутствует, вот только не пойму, в чем она?
R>Если серьезно, то пример кода в документации несложно найти.

Хорошо, давайте рассмотрим конкретный пример :

дано ASP.NET 2.0 с SessionState = Server, надо реализовать MVP для WebApp:

Есть View — SomeUserControl (SomeUserControl.ascx)
Есть Presenter — C# Class
Есть Model — в данном случае XmlNode который возвращает WebService

Для того что бы View дёргла Presenter ссылку на её надо, как предложил автор статьи, хранить в Presenter.

   public class Presenter
   {
      private Model _model = new Model();
      private IView _view;
   }

Время жизни Presenter это время жизни Session (иначе Presenter придётся каждый раз создавать, что не есть хорошо) соответственно Session хорошее место для его хранения (а в ViewState его засовывать это вообще бред ) но в вышеуказанной конфигурации реализация MVP усложняется, тем что приходится лепить костыли для хранения Presenter в памяти.

Я реализовал MVP для вышеуказанной конфигурации и оно работает, так что это трудности не составляет, но вдруг окажется что есть более лучшие варианты

Сильно упрощённо, моя схема была примерно такая :

   public interface IView
   {
         IPresenter Controller  
         ViewCallBackHandler(ControllerCommandBase command)
   }
  
   public interface ICommand
   {
   
   }
   
   public interface IPresenter
   {
           void OnCommand(IView view, ICommand command);   //command = class ViewCommandBase : ICommand           
   }
   
   public interface IService 
   {
      XmlNode GetData(ControllerCommandBase command)   // command = class ControllerCommandBase : ICommand
   }
   
   public class SomePresenter : IPresenter
   {
           
      public virtual void OnCommand(IView view, ICommand command)
      {
         if ( command is SomeViewCommand) CommandHandler(view, command as SomeViewCommand)
         
      }
      
      public virtual ControllerCommandBase MapCommand(ViewCommandBase viewCommand)
      {
         return commandTable[viewCommand];
      }
                   
      public void CommandHandler(IView view,  SomeViewCommand command)
      {
         ConcreteControllerCommand cmd =  MapCommand(command);
         
         SomeDate data = Service.GetData(cmd);
         
         view.ViewCallBackHandler(new AnotherControllerCommand("Refresh",new ControllerEventArgs(data)))
      }       

      public IService Service
      {
          get{ return ServiceFactory.GetService(); }
      }
   }

ControllerManager лежит в Application и создается по Application_Start (дада, лочим конечно ), и держит в себе control_id И ссылку на IPresenter который создаётся в IPresenter Controller по Singleton и добавляется при первом вызове get в ControllerManager. ControllerManager реализует IDisposable и уничтожается по Application_End .

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

D>дано ASP.NET 2.0 с SessionState = Server, надо реализовать MVP для WebApp:

D>Есть View — SomeUserControl (SomeUserControl.ascx)
D>Есть Presenter — C# Class
D>Есть Model — в данном случае XmlNode который возвращает WebService

Выглядеть это может примерно так:
Сначала описываем необходимые интерфейсы...

    public interface IMemento
    {
        // здесь описать всякие методы и свойства необходимые для идентификации 
        // и управления хранящемся объектом
        //
    }

     // интерфейс к сессии если вздумается хранить не в сессии, а в куках или во вьюстейте 
    // или вообще не хранить, если это десктоп приложение, достаточно подпихнуть нужную
    // реализацию этого интерфейса
    //
  public interface ISessionProvider
    {
        void Save(IMemento Memento);
        T Restore<T>() where T : IMemento; 
    }

Дальше пошли реализации.

  // хранитель данных модели
    //
    public class ModelMemento : IMemento
    {
        private XmlNode _node;

        public XmlNode Node
        {
            get { return _node; }
            set { _node = value;}
        }
    }

  // сама модель должна уметь сохраняться и восстанавливать свое состояние из Memento 
    //
    public class Model
    {
      .......
        
        public void Restore(ModelMemento Memento)
        {
            Node = ModelMemento.Node;
        }
        
        public IMemento Save()
        {
            ModelMemento memento = new ModelMemento();
            memento.Node = Node;
            return memento;
        }
    }

Теперь надо реализовать хранение мементо в сессии:

// в данном случае, для простоты, объекты хранятся по полному имени
//
public class SessionProvider : ISessionProvider
{
    private HttpSessionState _session =
        HttpContext.Current.Session;
    

    public void Save(IMemento Memento)
    {
        _session[typeof(T).FullName] = Memento;
    }

    public T Restore<T>() where T : IMemento
    {
        return (T) _session[typeof (T).FullName];
    }
}

Ну и осталось реализовать Presenter:

    public class Presenter
    {
        private Model _model = new Model();
        private IView _view;
        private ISessionProvider _session;

        // в конструкторе поддгружаем данные из сессии, если они там есть 
        // и восстанавливаем состояние модели
        //
        public Presenter(IView view, ISessionProvider session)
        {
            _session = session;
            ModelMemento modelMemento = _session.Restore<ModelMemento>();
            if (modelMemento != null)
                _model.Restore(modelMemento);
            
            _view = view;
      ....
        }
        
        // При изменении модели, сохраняем ее состояние в сессии.
        //
        private void OnModelChange(object sender, EventArgs e)
        {
       .....
            _session.Save(_model.Save());
        }
    }

D>Время жизни Presenter это время жизни Session
Нет. Presenter — это stateless объект, у него нет внутреннего состояния, которое надо хранить, он реализует лишь поведенческую логику. Зачем его запихивать в сессию?

D> (иначе Presenter придётся каждый раз создавать, что не есть хорошо)
Почему не хорошо? По умолчанию контроллером/презентером служит CodeBehind страничка, которая наследник Page, неужели ты и ее в сессию кладешь?

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

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

D>>дано ASP.NET 2.0 с SessionState = Server, надо реализовать MVP для WebApp:

D>>Есть View — SomeUserControl (SomeUserControl.ascx)
D>>Есть Presenter — C# Class
D>>Есть Model — в данном случае XmlNode который возвращает WebService

IB> // сама модель должна уметь сохраняться и восстанавливать свое состояние из Memento
IB>Теперь надо реализовать хранение мементо в сессии:

Теперь тоже самое, но сохранять Presenter.

D>>Время жизни Presenter это время жизни Session
IB>Нет. Presenter — это stateless объект, у него нет внутреннего состояния, которое надо хранить, он реализует лишь поведенческую логику. Зачем его запихивать в сессию?

*)Так как запланирована внутренняя коммуникация между контроллерами, но споткнулся на правильной реализации Presenter.

D>> (иначе Presenter придётся каждый раз создавать, что не есть хорошо)
IB>Почему не хорошо?

Смотри *)

IB>По умолчанию контроллером/презентером служит CodeBehind страничка, которая наследник Page, неужели ты и ее в сессию кладешь?

Естественно нет

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

D>Теперь тоже самое, но сохранять Presenter.
И какие проблемы? Для Presenter-а создается точно такой же memento объект как и для модели, если вдруг потребовалось состояние presenter-а хранить. Разницы никакой.

D>*)Так как запланирована внутренняя коммуникация между контроллерами, но споткнулся на правильной реализации Presenter.
И? Каким образом наличие комуникации между презентерами влияет на наличие или отсутствие у presenter-а состояния?

D>Естественно нет
Ну а почему тогда presenter так хочется в сессию запихнуть?

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

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

D>>Теперь тоже самое, но сохранять Presenter.
IB>И какие проблемы? Для Presenter-а создается точно такой же memento объект как и для модели, если вдруг потребовалось состояние presenter-а хранить. Разницы никакой.

Вот-вот, прошу пожалуста код, и не забыть сделать SessionState=Server.

D>>*)Так как запланирована внутренняя коммуникация между контроллерами, но споткнулся на правильной реализации Presenter.
IB>И? Каким образом наличие комуникации между презентерами влияет на наличие или отсутствие у presenter-а состояния?

D>>Естественно нет
IB>Ну а почему тогда presenter так хочется в сессию запихнуть?

коротко — потому-что надо мне так надо, так как считаю реализацию ASP.NET out-of-the-box неудобной для EA.

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

D>Вот-вот, прошу пожалуста код, и не забыть сделать SessionState=Server.
В восьмой раз говорю, код ничем не будет отличаться от того что я привел. Выносишь состояние Presenter-а в отдельный объект (memento) и хранишь как я показал. Хоть в sessionState=server, хоть в куках, хоть у себя в кармане.
Я не пойму, проблема что ли вынести состояние presenter-а в отдельный объект?

D>коротко — потому-что надо мне так надо,
Не, тебе так не надо.. В крайнем случае тебе надо хранить не presenter в сессии, а его состояние. А для того чтобы сохранить его состояние надо вынести это состояние в отдельный объект — это сложно?
Если уж не хочется создавать сам presenter, храни его в кеше, в конце-концов, а зависимое от пользователя состояние так же в memento.

D> так как считаю реализацию ASP.NET out-of-the-box неудобной для EA.
Хм.. Замнем для ястности. Если в "правильной" реализации предполагается хранение presenter-а в сессии, то лучше ASP.Net..

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

siv>Не по существу статьи...
siv>В тексте встретилась очепятка "задачь"
siv>Может стоит исправить?

Вообще, в тексте много опечаток и несуразиц, например, как можно унаследоваться от System.Windows.Forms?
Статья в целом неплохая, но вот эти оплошности оставляют неприятный осадок. Для ресурса такого уровня это выглядит очень странно
Неужели никто не делает корректуру перед публикацией?

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

ИБ>Авторы:
ИБ> Иван Бодягин

У меня возник следующий вопрос по статье.
В ней, как я понял из примера, описывается работа с пассивной моделью.
Но вот как быть если данные из View-a через Presenter-a попадают в модель
а далее модель по данным производит какие то действия(внутренние расчеты/обращения к источнику данных и т.п) и получает
новую информацию для отображения, далее ей требуется обновить один или несколько View-ов.
Как тогда получается взаимодействие модели View-а и Presenter-a ?
Можель обновляет вид только через Presenter или сама взаимодействует с видом (но тогда разрушается шаблон MVP)?!!!
Или же это уже не чистый MVP а нечто типа "Supervising Controller "?
Вобщем "все смешалось в королевстве Датском... тьфу в моей голове"

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

J>В ней, как я понял из примера, описывается работа с пассивной моделью.
Именно.

J>Как тогда получается взаимодействие модели View-а и Presenter-a ?
View и Presenter взаимодействуют точно так же... Presenter знает что он что-то поменял в модели, опрашивает модель на предмет изменений и обновляет соответствующие View. Если в системе существуют несколько независимых Presenter-ов, то внесший изменения презентер может взаимодействовать с остальными через события, либо ввести еще одину триаду уровнем выше, которая через свой презентер контролирует все нижележащие...

J>Модель обновляет вид только через Presenter
При таком раскладе только через Presenter.

J> или сама взаимодействует с видом (но тогда разрушается шаблон MVP)?!!!
Строго говоря не разрушается, но мне такой расклад не симпатичен.. В крайнем случае я предпочитаю, чтобы модель уведомляла презентеры, но не вью.

J>Или же это уже не чистый MVP а нечто типа "Supervising Controller "?
Supervising Controller — всего лишь один из вариантов MVP...

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

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

J>>В ней, как я понял из примера, описывается работа с пассивной моделью.
IB>Именно.
ок значит я что то еще понимаю в этой жизни

J>>Как тогда получается взаимодействие модели View-а и Presenter-a ?
IB>View и Presenter взаимодействуют точно так же... Presenter знает что он что-то поменял в модели, опрашивает модель на предмет изменений и обновляет соответствующие View. Если в системе существуют несколько независимых Presenter-ов, то внесший изменения презентер может взаимодействовать с остальными через события, либо ввести еще одину триаду уровнем выше, которая через свой презентер контролирует все нижележащие...

Значит тут есть жесткая связка модели и Presenter-a. Я так понимаю что Presenter должен подписаться на некоторые события модели которые уведомляют о
изменении модели и соотвецтвующим образом изменить View и остальные Presenter-ы которые с ним связаны?!
Если так тогда более менее понятно.

Тогда вот такой момент поправте если что не так к примеру во View есть кнопка с сохранием текущего документа или же чего бы то ни было.
Далее логика обработки события от этой кнопки переходит в Presenter и он определяет (используя состояние модели или еще как либо ) что в данный момент можно сохраниться или показывает соотвецтвующий диалог, а далее если что пошло не так то отлавливает все исключения и в соотвецтвующим образом модифицирует модель и/или View. Т.е. вся логика работы программы разделяется в моедли и Presenter-e а View не имеет собственной логики.. Ход мыслей правилен или может я всетаки что то упустил?

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

J>Значит тут есть жесткая связка модели и Presenter-a.
Только со стороны Presenter-а, который естественно знает о модели с которой работает, модель же о presenter-е ничего не знает.

J> Я так понимаю что Presenter должен подписаться на некоторые события модели которые уведомляют о
J>изменении модели и соотвецтвующим образом изменить View и остальные Presenter-ы которые с ним связаны?!
Не обязательно.. Presenter же сам вносит изменения, следовательно знает, что модель изменилась и на основании этого может и опросить модель и разослать уведомления — нет необходимости навешивать на модель события.

J> Т.е. вся логика работы программы разделяется в моедли и Presenter-e а View не имеет собственной логики..
Совершенно верно. Основная идея — сделать View как можно проще и повозможности вообще лишить его логики.

Здравствуйте, Иван Бодягин, Вы писали:

В целом MVC и Document-View, как его логическое продолжение вполне

Дальше читать как-то сразу расхотелось.

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


A>

В целом MVC и Document-View, как его логическое продолжение вполне

A>Дальше читать как-то сразу расхотелось.

Почему?

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

ИБ>Авторы:
ИБ> Иван Бодягин


Вот не могу всетаки полностью мозгами принять подход MVP, тяжело после MVC перестроиться

Никак не соображу блин как в подход предлагаемый MVP может вписаться биндинг, т.е. автоматическая
привязка данных к контролу ...
Мои мысли по этому поводу
1) привязку (указанние что на что биндить) данных к View-у может осуществитиь Presenter
2) при изменении значений во View-е,Presenter-у прийдется вклиниваться в биндинг и каким то образом перехватывать
измененные значения и запихивать их в модель... или же пропускать мимо себя данные от View-а прямо к модели. Но так появляется
связь View-а и Модели что является разрушением шаблона MVP, т.к. имхо для разделения вида и модели при помощи
внесения между ними посредника в виде Presenter-а, он предназначен.
3) Отказаться от биндинга и руками прописывать связи всех полей данных в контролы и так же в событиях их отслеживать.
(но по моему это никуджа не годится — назад в каменый век).
Вобщем мозги еще не до конца не переварили этот шаблон. Хотя без биндинга он нормально проходит.

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

A>>

В целом MVC и Document-View, как его логическое продолжение вполне

A>>Дальше читать как-то сразу расхотелось.
J>Почему?

Ну наверное потому что Document-View это не логическое продолжение Model-View-Controller, а примитивизация.
Кстати сокрушательства автора, о том как сложно реализовать MVC в .Net меня что-то не очень убедили. Да, действительно в WinAPI отрисовка элемента управления и его реакция на внешний мир реализуются в одной функции WndProc, а в Windows.Forms как результат, в одном, унаследованном от Control, классе. Но почему этот класс не может делегировать рисование одному классу (кстати уже так и есть, поглядите классы *Renderer), а реакцию на внешний мир другому я не монимаю. Вернее не понимаю, почему

код, который порождают среды и библиотеки провоцирует интегрировать Контроллер в Представление.

Если уж на то пошло, провоцирует не генерируемый код, а WinAPI. И не так уж и провоцирует. Тот кому это надо, Controller от View отделит без проблем. Но что самое существенное, почему это всё вдруг попало в раздел "Недостатки MVC и Document-View"?! С какой радости особенности реализации Windows.Forms вдруг стали недостатками MVC?

И, главное, что такое MVP? Это какой-то очень странный паттерн резко повышающий связность, потому что теперь практический у всех есть ссылки на всех. Об этом знает и сам автор

Однако здесь, в отличие от случая с Моделью, создание конкретного экземпляра конкретного класса Представления, может обернуться большими неудобствами. При наличии тесной связи между Presenter-ом и Представлением будет сложно реализовать замену Представлений и использование нескольких Представлений для одного Presenter-а, к тому же, это затруднит независимое тестирование Presenter-а

Взамен, в качестве костыля, нам предлагают у всех View реализовать некоторый интерфейс IView. Это уменьшило связность? Ничуть! Посмотрите на интерфейс — он практически дублирует модель. В принципе и раньше представление знало о модели, но раньше эти знания не навязывались. Представление вполне могло интересоватся лишь частью модели. Кроме того, то что модель теперь не медиатор влечёт и другие, куда более существенные недостатки.
Во-первых, раньше модель могла расслытать оповещения только когда действительно что-то изменилось, потому что ей-то уж виднее совпадает старое значение с новым или нет. Теперь это не так.
Во-вторых, модель могла расслать оповещения об изменении группы свойств. То есть, например, не XChanged, YChanged, а PositionChanged, а View в свою очередь считывать свойства группами. Теперь же нельзя по отдельности вызывать SetX, SetY. Это во многих случаях повлечёт неадекватное поведение View, когда часть свойств имеют старые значения, а часть новые. Приходится делать транзакции в виде операторных скобок BeginUpdate/EndUpdate.

Вобщем то, что тов. Бодягин представляет как последнее достижение программистской мысли, на мой взгляд просто пример неудачного дизайна. Я вообще уже успел заметить что некоторые паттерны проектирования он склонен воспринимать крайне оригинально.

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

A>Ну наверное потому что Document-View это не логическое продолжение Model-View-Controller, а примитивизация.
Можешь на пальцах объяснить, почему примитивизация не может быть логическим продолжением?

A>Кстати сокрушательства автора, о том как сложно реализовать MVC в .Net меня что-то не очень убедили.
Видно, что дальше ты действительно не читал, ну а если не читал, зачем тогда критиковать? В смешное положение себя ставишь.. )

A> Вернее не понимаю, почему

код, который порождают среды и библиотеки провоцирует интегрировать Контроллер в Представление.

А ты подумай..

A> С какой радости особенности реализации Windows.Forms вдруг стали недостатками MVC?
Сам же написал, не Windows.Forms, а WinAPI... =)
Ром, если уж берешься критиковать, то во-первых, дочитывай все-таки до конца и внимательно, а во-вторых, будь последователен.
А то твое желание задеть явно превышает возможности.. )

A>И, главное, что такое MVP? Это какой-то очень странный паттерн резко повышающий связность, потому что теперь практический у всех есть ссылки на всех.
Роооом, я тебя очень прошу. Давай, впредь, прежде чем критиковать ты сначала разберешься в вопросе, хорошо? А-то совсем как-то некрасиво получается, тебе приходится азы растолковывать. Причем ладно бы ты просто учился, а то ведь агрессивно упорствуешь.. =)

A>Взамен, в качестве костыля, нам предлагают у всех View реализовать некоторый интерфейс IView. Это уменьшило связность? Ничуть!
Рома, ну не смеши.. Ну право-слово, твое желание найти у меня ошибки лишь демонстрирует твое .... эээ.. слабое знание предмета )
Во-первых, прежде чем разбираться с высокоуровневыми паттернами типа MVC/MVP, разберись с основами, почитай про архитектурный принцип Inversion of Control (у Фаулера он описан в виде паттерна Dependency Injection), и про вопросы связности системы, которые он решает. Для справки, на основе ровно этого принципа построена Java-вская визуальная библиотека Swing (что характерно тот самый MVC), которая по праву считается одной из лучших в архитектурном плане.. Хочешь сказать у ребят тоже проблемы с дизайном?
А во-вторых, опять-таки для справки, практически во всех вариантах MVC, включая оригинальный смолтолковский, View обладает well-known интерфейсом и все взаимодействие view и остальных частей системы происходит именно через этот интерфейс (как у меня и описано). Это не особенность MVP это практически основа паттерна MVC — тот принцип на котором он построен. И в статье, я объяснил, почему сделано именно так, но ты же дальше второго раздела не читал..

A> Посмотрите на интерфейс — он практически дублирует модель. В принципе и раньше представление знало о модели, но раньше эти знания не навязывались. Представление вполне могло интересоватся лишь частью модели.
Ну уж тот факт, что в данном случае интерфейс похож на модель лишь в силу примитивизма примера должен быть очевиден даже для тебя.. Ром, не пытайся казаться менее сообразительным.. ) Надеюсь тебе не надо объяснять, что интерфейс декларирует лишь то что надо для работы данного типа представлений, а вовсе не всю модель?

A>Кроме того, то что модель теперь не медиатор влечёт и другие, куда более существенные недостатки.
A>Во-первых, раньше модель могла расслытать оповещения только когда действительно что-то изменилось, потому что ей-то уж виднее совпадает старое значение с новым или нет. Теперь это не так.
Опять невнимательно читал? Чем отдельный медиатор для набора моделей отличается от презентера, который в MVP берет функции медиатора на себя? И каким магическим образом медиатору станет известно о моделях больше, чем сами модели захотят о себе сообщить?

A>Вобщем то, что тов. Бодягин представляет как последнее достижение программистской мысли, на мой взгляд просто пример неудачного дизайна.
Да-да, и Фаулер, тоже хреновый архитектор, между нами говоря, и Component UI App Block (как раз по принципу MVP построен), тоже отстой полный, и только Рома Акопов, знает как правильно дизайнить..

A> Я вообще уже успел заметить что некоторые паттерны проектирования он склонен воспринимать крайне оригинально.

То есть, называть экземпляр — экземпляром, а не "точной входа

Автор: IB
Дата: 30.10.06

" и не уродовать до неузнаваемости паттерн Singleton — это называется "воспринимать крайне оригинально" ?
А тот факт, что MethodName(Int16 i) оказывается 65535 точек входа — вообще можно признать шуткой месяца
Так что молчал бы уж, про оригинальность восприятия...

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

J>Никак не соображу блин как в подход предлагаемый MVP может вписаться биндинг, т.е. автоматическая
J>привязка данных к контролу ...
По разному, вариантов довольно много.
Полярные случаи — если представление работает только с примитивными типами, то в презентере происходит прямая привязка модели или объекта DTO к интерфейсу View, если же представление само умеет работать с DTO, то привязка происходит уже внутри представления, а взаимодействие с презентером происходит на уровне DTO объектов...

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

A>>Ну наверное потому что Document-View это не логическое продолжение Model-View-Controller, а примитивизация.
IB>Можешь на пальцах объяснить, почему примитивизация не может быть логическим продолжением?

Могу (элементарно по хронологии появления), но не хочу скатыватся во флейм.

A>>С какой радости особенности реализации Windows.Forms вдруг стали недостатками MVC?
IB>Сам же написал, не Windows.Forms, а WinAPI... =)

Windows.Forms хотя и использует WinAPI, но являясь слишком тонкой обёрткой не изменило ситуацию в корне.

IB>Ром, если уж берешься критиковать, то во-первых, дочитывай все-таки до конца и внимательно, а во-вторых, будь последователен.

Вообще-то я дочитал.

IB>А то твое желание задеть явно превышает возможности.. )

У тебя проблемы, мания преследования, хочешь об этом поговорить?

IB>Во-первых, прежде чем разбираться с высокоуровневыми паттернами типа MVC/MVP, разберись с основами, почитай про архитектурный принцип Inversion of Control (у Фаулера он описан в виде паттерна Dependency Injection), и про вопросы связности системы, которые он решает. Для справки, на основе ровно этого принципа построена Java-вская визуальная библиотека Swing (что характерно тот самый MVC), которая по праву считается одной из лучших в архитектурном плане.. Хочешь сказать у ребят тоже проблемы с дизайном?

У тебя проблемы с логикой, ты чтобы показать что MVP не повышает связность, говоришь что в Swing используется MVC.

IB>А во-вторых, опять-таки для справки, практически во всех вариантах MVC, включая оригинальный смолтолковский, View обладает well-known интерфейсом и все взаимодействие view и остальных частей системы происходит именно через этот интерфейс (как у меня и описано).

А вот это уже просто не правда. View подписывается на события модели, но при этом сам никакого интерфейса не предоставляет. Так что не надо ля-ля. Слабо знание предмета как раз у тебя. И твои "Гы-ы-ы, Рома, ЛОЛ, какой ты тупой" лично на меня никакого впечатления не произвели.

IB>Это не особенность MVP это практически основа паттерна MVC — тот принцип на котором он построен. И в статье, я объяснил, почему сделано именно так, но ты же дальше второго раздела не читал..

Паттерн MVC не требует от View реализации каких бы то ни было интерфейсов. Так что всё дальнейшее так же не верно.

IB> То есть, называть экземпляр — экземпляром, а не "точной входа

Автор: IB
Дата: 30.10.06

" и не уродовать до неузнаваемости паттерн Singleton — это называется "воспринимать крайне оригинально" ?
IB> А тот факт, что MethodName(Int16 i) оказывается 65535 точек входа — вообще можно признать шуткой месяца

Это действительно шутка, только твоя. Очередной бред, который мне приписал, так и не поняв смысла сказанного.

IB> Так что молчал бы уж, про оригинальность восприятия...

Последний раз, для тех кто в танке. Точка входа это не метод. Метод с факсированными значениями парметров так же не является точкой входа. Всё чем я могу тебе помочь, так это просто привести пример:

CultureInfo ci1 = CultureInfo.GetCultureInfo(1049);
CultureInfo ci2 = CultureInfo.GetCultureInfo("ru-RU");
bool test = ci1 == ci2; // Бодягин не верит, но тут будет true.

GetCultureInfo(1049) и GetCultureInfo("ru-RU") это одна и та же точка входа, но разные методы с разными параметрами.

---

Вобщем в хамстве ты разбираешься лучше чем в паттернах. Счастливо оставаться. Мне за твоё обучение никто не платит.

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

A>Могу (элементарно по хронологии появления), но не хочу скатыватся во флейм.
А ты не скатывайся, просто посмотри на хронологию.. )

A>Windows.Forms хотя и использует WinAPI, но являясь слишком тонкой обёрткой не изменило ситуацию в корне.
А кто сказал, что должно было изменить? Ром, ты хотя бы себя читай, что ли.. )

A>Вообще-то я дочитал.
Значит плохо дочитал...

A>У тебя проблемы, мания преследования, хочешь об этом поговорить?
A>У тебя проблемы с логикой, ты чтобы показать что MVP не повышает связность, говоришь что в Swing используется MVC.
Рома, не ищи проблемы у меня, разберись сначала со своими..
Например, с внимательным чтением — чтобы показать, что MVP не повышает связность, я говорю, что точно так же поступает и MVC и конкретная реализация — Swing и даже принцип привожу на котором это основано, почитай на досуге. Так понятнее?

A>А вот это уже просто не правда.
Ну ты бы разобрался что ли, прежде чем столь громкими словами кидаться..

A> View подписывается на события модели, но при этом сам никакого интерфейса не предоставляет.
А как по твоему View с контроллером/презентером взаимодействует? Голубиной почной? Хинт: возможность брать данные у модели и наличие интерфейса — ортогональные вещи..
А впрочем, что я распинаюсь, мне-то ты все равно не поверишь, просто из принципа. Спорь лучше с википедией. Обрати внимание на диаграму MVC в верхнем правом углу, там очень хорошо показано кто как и с кем взаимодействует, с коментариями. Представление знает только о модели, контроллер знает и о модели и о представлении, модель не знает ни о ком. Дальше разжевать или понятно?

A> Рома, ЛОЛ, какой ты тупой" лично на меня никакого впечатления не произвели.
Что-ты, Рома, никакой попытки произвести впечатление — это просто искреннее недоумение нелепостью предъявленых претензий..

A>Паттерн MVC не требует от View реализации каких бы то ни было интерфейсов.
Ты под интерфейсом что понимаешь? MVC требует, чтобы контроллер знал о презентере, но не наоборот.
Если же речь о ключевом слове interface, то да, не требует, но чем это черевато я в статье показал, можешь еще раз перечитать.. Еще один хинт — view меняется гораздо чаще чем любой другой компонент триады.

A>Так что всё дальнейшее так же не верно.
Что дальнейшее?

A>Точка входа это не метод. Метод с факсированными значениями парметров так же не является точкой входа.
А что является? Я долго от тебя пытался этого добиться, но ответа так и не получил.

A>bool test = ci1 == ci2; // Бодягин не верит, но тут будет true.
И кто из нас после этого приписками занимается?

A>GetCultureInfo(1049) и GetCultureInfo("ru-RU") это одна и та же точка входа, но разные методы с разными параметрами.
Да байта ради, но ты-то утверждал обратное, что один метод означает несколько разных "точек входа". Так что причем здесь это?
Ром, еще раз говорю — не передергивай, не умеешь..

A> Мне за твоё обучение никто не платит.
Давай я лучше тебе платить буду, чтобы ты других не учил... Право-слово, мне же дешевле выйдет..

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

A>>Windows.Forms хотя и использует WinAPI, но являясь слишком тонкой обёрткой не изменило ситуацию в корне.
IB>А кто сказал, что должно было изменить? Ром, ты хотя бы себя читай, что ли.. )

Не должно, но могло.

IB>Рома, не ищи проблемы у меня, разберись сначала со своими..

У меня проблем нет

IB>Например, с внимательным чтением — чтобы показать, что MVP не повышает связность, я говорю, что точно так же поступает и MVC и конкретная реализация — Swing и даже принцип привожу на котором это основано, почитай на досуге. Так понятнее?

Ты как-то странно опустил аргумент про BeginUpdate/EndUpdate, как будто его и не было вовсе. И про то что обощённый IView не слишком удобная штука. Я уже не говорю о том, что данные во View в результате такой реализации будут копиями (ща ещё про глубокое копирование поговорим) данных в Model (нерациональное расходование памяти, бла-бла-бла). Пока ты тут теоретизируешь, я уже от MVP на собственно опыте отказался Буду краток — неэффективно. Слишком много сопутствующего кода надо реализовывать для переливания из пустого в порожнее, разного рода передачи данных из одних классов в другие.

A>>View подписывается на события модели, но при этом сам никакого интерфейса не предоставляет.
IB>А как по твоему View с контроллером/презентером взаимодействует? Голубиной почной? Хинт: возможность брать данные у модели и наличие интерфейса — ортогональные вещи..

Интерефйс там просто не нужен. А раз не нужен, то и реализовывать его не к чему.

IB>А впрочем, что я распинаюсь, мне-то ты все равно не поверишь, просто из принципа. Спорь лучше с википедией. Обрати внимание на диаграму MVC в верхнем правом углу, там очень хорошо показано кто как и с кем взаимодействует, с коментариями. Представление знает только о модели, контроллер знает и о модели и о представлении, модель не знает ни о ком. Дальше разжевать или понятно?

Мне вполне это всё понятно, пойми и ты что там означают сплошные линии, а что пунктирные.

A>>Паттерн MVC не требует от View реализации каких бы то ни было интерфейсов.
IB>Ты под интерфейсом что понимаешь? MVC требует, чтобы контроллер знал о презентере, но не наоборот.
IB>Если же речь о ключевом слове interface, то да, не требует, но чем это черевато я в статье показал, можешь еще раз перечитать.. Еще один хинт — view меняется гораздо чаще чем любой другой компонент триады.

Под интерфейсом я понимаю то что в .Net называется интерфейсом, так как примеры у тебя на C#. Если быть совсем уж точным, то конечно View должен мочь обновлятся. Другое дело как это сделать. В .Net модель может предоставлять набор XyzChanged событий, на которые все кому надо подпишутся. В каких-то других условиях возможно пришлось бы реализовать IView с методом UpdateXyz, но уж точно не стоит прегонять во View копию данных через SetXyz. Ещё повторюсь почему это плохо:

Мы вынуждены обощённо передавать во View все данные модели, либо реализовать систему оповещения какая часть данных нужна.

Мы вынуждены извне поддерживать целостность данных во View.

A>>Точка входа это не метод. Метод с факсированными значениями парметров так же не является точкой входа.
IB>А что является? Я долго от тебя пытался этого добиться, но ответа так и не получил.

Отвечаю — абстракция, некоторый глобальный механизм получения одного и того же экземпляра некоторого класса. В каноническом виде она действительно совпадает с методом Instance() и только лишь совпадает. В реальной реализации "расширенного синглтона" у неё может не быть чёткого физического представления.

A>>GetCultureInfo(1049) и GetCultureInfo("ru-RU") это одна и та же точка входа, но разные методы с разными параметрами.
IB>Да байта ради, но ты-то утверждал обратное, что один метод означает несколько разных "точек входа". Так что причем здесь это?

Я утверждал, что один метод с параметром это может быть несколько точек входа. То что Method(Int16) это всегда 65536 точек входа конечно же бред, который ты мне почему-то приписывал.
Если на примере с CultureInfo ты наконец-то понял что я имел ввиду, я очень рад.

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

A>Интерефйс там просто не нужен. А раз не нужен, то и реализовывать его не к чему.
Насколько понял, в споре сравнивается с одной стороны активная модель MVC, которая оповещает представления, а с другой стороны, неактивная модель MVP, оповещение представления об изменении которой берет на себя предъявитель. Не вижу причин, почему не имеют право на жизнь каждый из этих вариантов.

Оповещение активной моделью представления в Java, к примеру, производится посредством шаблона проектирования Observer, когда представления реализуют интерфейс подписки, по которому модель и производит оповещение, то есть интерфейс в любом случае имеет место. То, что в C# событийная модель работает не на интерфейсах, а на делегатах — собственно сам шаблон проектирования MVP не меняет, да и по сути является функциональным аналогом.

A>Паттерн MVC не требует от View реализации каких бы то ни было интерфейсов.
Гм... туда же, см. выше.

A>Под интерфейсом я понимаю то что в .Net называется интерфейсом, так как примеры у тебя на C#. Если быть совсем уж точным, то конечно View должен мочь обновлятся. Другое дело как это сделать. В .Net модель может предоставлять набор XyzChanged событий, на которые все кому надо подпишутся. В каких-то других условиях возможно пришлось бы реализовать IView с методом UpdateXyz, но уж точно не стоит прегонять во View копию данных через SetXyz. Ещё повторюсь почему это плохо:
A>

Мы вынуждены обощённо передавать во View все данные модели, либо реализовать систему оповещения какая часть данных нужна.
A>

Мы вынуждены извне поддерживать целостность данных во View.
Так и не понял, в чем координальное различие оповещения из модели представления и оповещения из предъявителя представления? В любом варианте можно организовать оповещение об изменении любой части модели: в первом случае изменится интерфейс (или делегаты в C#) подписки представления на изменения модели, во втором случае интерфейс представления, по которому оно принимает события изменения модели от предъявителя.

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

J>Здравствуйте, Иван Бодягин, Вы писали:

ИБ>>Статья:
ИБ>>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

ИБ>>Авторы:
ИБ>> Иван Бодягин


J>Вот не могу всетаки полностью мозгами принять подход MVP, тяжело после MVC перестроиться

J>Никак не соображу блин как в подход предлагаемый MVP может вписаться биндинг, т.е. автоматическая
J>привязка данных к контролу ...
в ASP.NET мы завели два метода в IView: Form2Data и Data2Form, и с помощью библиотеки oт MetaCommunication (см. проекты) привязываем уже в самой разметке aspx/ascx.
Для winforms что-то подобное (но точно не скажу, не смотрел) умеет BLToolkit (опять же в проекты).

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

A>Не должно, но могло.
Ну и? К чему это?

A>У меня проблем нет
Ага, вижу..

A>Ты как-то странно опустил аргумент про BeginUpdate/EndUpdate, как будто его и не было вовсе.
Это не аргумент, это твои .. эээ. теоретические построения.

A> И про то что обощённый IView не слишком удобная штука.
Кто тебе сказал, что он обобщенный? Ну вот откуда ты это взял, расскажи пожалуйста? Ну не смешно уже даже, пожалуйста, в очередной раз очень тебя прошу, читай внимательно, а то приходится одно и то же по десять раз повторять.

A> Я уже не говорю о том, что данные во View в результате такой реализации будут копиями
Предложи альтернативную, расскажи, как ты View собираешься обновлять.

A>(нерациональное расходование памяти, бла-бла-бла).


A> Пока ты тут теоретизируешь, я уже от MVP на собственно опыте отказался


A>Интерефйс там просто не нужен. А раз не нужен, то и реализовывать его не к чему.
Перечитай еще раз соответствующий раздел в статье, внимательно... Тебе-то он может быть и не нужен, а вот во всех внятных реализациях, (e. g. тот же Swing) он присутствует, и там сказано почему.

A>Мне вполне это всё понятно,
Сомневаюсь, было бы понятно, не спорил бы...

A> пойми и ты что там означают сплошные линии, а что пунктирные.
Советуюу тебе обратить пристальне внимание на стрелочки..

A> Если быть совсем уж точным, то конечно View должен мочь обновлятся. Другое дело как это сделать. В .Net модель может предоставлять набор XyzChanged событий, на которые все кому надо подпишутся.
A> В каких-то других условиях возможно пришлось бы реализовать IView с методом UpdateXyz, но уж точно не стоит прегонять во View копию данных через SetXyz.
Еще раз, для младшего сержантского состава.. Интерфейса и события — независимые сущности, это значит не пересекающиеся и не взаимоисключающие, они существуют одновременно и осуществляют обмен данными в разных направлениях. Почему ты валишь все в одну кучу?
События View оповещают Контроллер о том, что View изменился (то что ты описываешь), с помощю же интерфейса Контроллер обновляет View и считывает изменения. Такая схема позволяет View на парится о том, что за Контроллер с ним работает — уменьшает связность. =)
Почему приходится азы разжевывать?

A>Ещё повторюсь почему это плохо:
A>

Мы вынуждены обощённо передавать во View все данные модели, либо реализовать систему оповещения какая часть данных нужна.
Кто тебя к этому вынудил? Во View надо передавать только те данные, которые нужны конкретному View.
Зачем тебе понадобилась система оповещения?

A>

Мы вынуждены извне поддерживать целостность данных во View.
Для чего? Какие у тебя могут появиться проблемы с целостностью из-за наличия интерфейса?

A>Отвечаю — абстракция, некоторый глобальный механизм получения одного и того же экземпляра некоторого класса.
Почему именно одного и того же? Если это абстракция — почему ты ограничиваешь термин "точка доступа" конкретным паттерном?

A>В реальной реализации "расширенного синглтона" у неё может не быть чёткого физического представления.
Что такое "расширеный" синглтон? Как может не быть четкого физического представления у ключевой сущности паттерна?
Ты, похоже сам уже запутался..

A>Я утверждал, что один метод с параметром это может быть несколько точек входа.
Ага. Так в каких же случая метод с параметом — несколько точек доступа, а в каких одна? Могу я глядя на метод, но не зная ее реализации, утверждать, что это вот одна "точку доступа", а здесь вот у нас их на самом деле несколько?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IB>События View оповещают Контроллер о том, что View изменился (то что ты описываешь), с помощю же интерфейса Контроллер обновляет View и считывает изменения. Такая схема позволяет View на парится о том, что за Контроллер с ним работает — уменьшает связность. =)
Сделал несколько иначе. Предъявитель по сути должен уметь работать с несколькими представлениями, которые хотят отображать одну и ту же модель, которой управляет предъявитель. Поэтому все представления при инициализации сами обращается к нужному им предъявителю, соответственно имеют прямые ссылки на него. Работают с ними не по событиям, как у вас в статье, а напрямую по шаблону проектирования Command. А вот предъявитель уже поэтому не "заморачивается" тем, какие именно представления с ним работают — оповещение организовано почти как и у вас по шаблону проектирования Observer, то есть предъявитель является публикатором, на который подписываются представления — подписчики: предъявитель изменяет модели и по завершению производит оповещение всех подписанных представлений. Вроде бы ничему не противоречит такое построение, как по-вашему?

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

A>>Под интерфейсом я понимаю то что в .Net называется интерфейсом, так как примеры у тебя на C#. Если быть совсем уж точным, то конечно View должен мочь обновлятся. Другое дело как это сделать. В .Net модель может предоставлять набор XyzChanged событий, на которые все кому надо подпишутся. В каких-то других условиях возможно пришлось бы реализовать IView с методом UpdateXyz, но уж точно не стоит прегонять во View копию данных через SetXyz. Ещё повторюсь почему это плохо:
A>>

Мы вынуждены обощённо передавать во View все данные модели, либо реализовать систему оповещения какая часть данных нужна.
A>>

Мы вынуждены извне поддерживать целостность данных во View.
R>Так и не понял, в чем координальное различие оповещения из модели представления и оповещения из предъявителя представления? В любом варианте можно организовать оповещение об изменении любой части модели: в первом случае изменится интерфейс (или делегаты в C#) подписки представления на изменения модели, во втором случае интерфейс представления, по которому оно принимает события изменения модели от предъявителя.

Простой пример, хотя и слегка надуманный.
Пусть у нас в качестве данных двумерная точка (System.Drawing.Point если угодно). Так случилось, что меняются за раз обе её координаты. Пусть в начале координаты (3;7), а стали (5; 6). В MVC модель отшлёт виду оповещение CoordsChanged, вид прочтёт за раз обе координаты, и отрисует точку в новом положении. В MVP сложнее, оповещений нет. Но и сказать виду SetX(5); SetY(6) нельзя, потому что между этми вызовами вид отрисует точку по координатам (5;7). Надо делать BeginUpdate, SetX, SetY, EndUpdate. Кроме того виду может понадобится только X-координата. В MVC только она видом и считывается, в MVP информация о том что именно надо виду теряется и приходится перегонять туда обе координаты, даже если в этом нет необходимости.
Понятно, что объект Point слишком мал и пример выглядит странно, но представьте себе что у нас более сложные композитные данные.

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

A>Пусть у нас в качестве данных двумерная точка (System.Drawing.Point если угодно). Так случилось, что меняются за раз обе её координаты. Пусть в начале координаты (3;7), а стали (5; 6). В MVC модель отшлёт виду оповещение CoordsChanged, вид прочтёт за раз обе координаты, и отрисует точку в новом положении. В MVP сложнее, оповещений нет.
Это только в примере автора так, для наглядности этого было достаточно. Выше писал, что предъявитель может в принципе оповещать представления, почти абсолютно повторяя оповещение представлений моделью в MVC. Какая собственно разница-то?

A> Но и сказать виду SetX(5); SetY(6) нельзя, потому что между этми вызовами вид отрисует точку по координатам (5;7). Надо делать BeginUpdate, SetX, SetY, EndUpdate. Кроме того виду может понадобится только X-координата. В MVC только она видом и считывается, в MVP информация о том что именно надо виду теряется и приходится перегонять туда обе координаты, даже если в этом нет необходимости.
Гм... В MVC модель рассылает события методами SetX, SetY, SetBoth (интерфейс/делегат реализуют представления), аналогом в MVP может выступить (если говорить о примере автора) одноименные методы интерфейса IView: SetX, SetY, SetBoth (опять же данный интерфейс реализуют представления). Где разница? В упор не вижу.

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

R>Гм... В MVC модель рассылает события методами SetX, SetY, SetBoth (интерфейс/делегат реализуют представления), аналогом в MVP может выступить (если говорить о примере автора) одноименные методы интерфейса IView: SetX, SetY, SetBoth (опять же данный интерфейс реализуют представления). Где разница? В упор не вижу.

Я боялся, что простота данных введёт в заблеждение. Вобщем-то у меня нету никакого SetBoth.
Это когда два компонента руки тянутся это написать, а когда их, скажем 4? 64 разных метода? Нет, в результате вернёмся к операторным скобкам BeginUpdate/EndUpdate.

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

A>>Ты как-то странно опустил аргумент про BeginUpdate/EndUpdate, как будто его и не было вовсе.
IB>Это не аргумент, это твои .. эээ. теоретические построения.

ГЫ. Ударились в демагогию? Покажи мне реализацию обновления сложной модели без BeginUpdate/EndUpdate. Я тут про точку рядом написал.

A>> И про то что обощённый IView не слишком удобная штука.
IB>Кто тебе сказал, что он обобщенный? Ну вот откуда ты это взял, расскажи пожалуйста? Ну не смешно уже даже, пожалуйста, в очередной раз очень тебя прошу, читай внимательно, а то приходится одно и то же по десять раз повторять.

Он обобщённый потому что интерфейс который реализуют все виды.

IB>Предложи альтернативную, расскажи, как ты View собираешься обновлять.

Например считывать из модели по мере необходимости. Про virtual list-view слыхал? А про DataSource вместо Items.Add?

IB>События View оповещают Контроллер о том, что View изменился (то что ты описываешь),

View изменился?! Мда, приехали. Я такой бред никогда не нёс.

IB>Кто тебя к этому вынудил? Во View надо передавать только те данные, которые нужны конкретному View.
IB>Зачем тебе понадобилась система оповещения?

Затем что ты не знаешь заранее какие данные нужны конкретному View.

A>>

Мы вынуждены извне поддерживать целостность данных во View.
IB>Для чего? Какие у тебя могут появиться проблемы с целостностью из-за наличия интерфейса?

См пример про точку в соседней ветке.

A>>Отвечаю — абстракция, некоторый глобальный механизм получения одного и того же экземпляра некоторого класса.
IB>Почему именно одного и того же?

Потому что это Синглтон

IB>Что такое "расширеный" синглтон? Как может не быть четкого физического представления у ключевой сущности паттерна?
IB>Ты, похоже сам уже запутался..

Я не запутался. Есть синглтон из "Банды четырёх", где предлагается его расширить чтобы возвращать несколько экземпляров. Вот о таком расширенном я и говорю. А включать дурака не надо, мы это последние несколько дней обсуждаем. С чего это тебе именно сегодня вдруг стал непонятен термин расширеный синглтон?

IB>Ага. Так в каких же случая метод с параметом — несколько точек доступа, а в каких одна?

Зависит от реализации метода.

IB>Могу я глядя на метод, но не зная ее реализации, утверждать, что это вот одна "точку доступа", а здесь вот у нас их на самом деле несколько?

Нет, не можешь.

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

A>Я боялся, что простота данных введёт в заблеждение. Вобщем-то у меня нету никакого SetBoth.
Если нет, то и в случае MVC, и в случае MVP одно и тоже, будет, как вы говорите, эти сотые доли секунд, когда представление обновит графический примитив отображающий одну координату, но еще не успеет обновить отображение другой координаты. И опять же вопрос: где тут разница, якобы на основании которой вы ставите MVC выше MVP?

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

A>В MVP сложнее, оповещений нет. Но и сказать виду SetX(5); SetY(6) нельзя, потому что между этми вызовами вид отрисует точку по координатам (5;7). Надо делать BeginUpdate, SetX, SetY, EndUpdate. Кроме того виду может понадобится только X-координата. В MVC только она видом и считывается, в MVP информация о том что именно надо виду теряется и приходится перегонять туда обе координаты, даже если в этом нет необходимости.
Кто сказал? Опять все претензии из-за того, что невнимательно прочитал?
1. От того, что нет оповещений ничуть сложнее не стало — изменения в модель попадают через презентер, значит он знает, что изменения были внесены и совершенно спокойно может обновить представление, я писал об этом уже несколько раз.
2. Опять-таки я несколько раз упоминал о том, что Представление не бязательно должно работать с примитивными типами, если очень нужно то в интерфейсе вполне может быть описан метод SetPoint(Point p), хотя это и усложнит view.
3. В MVP вполне могут быть оповещения представлений моделью, о чем опять-же сказано в статье, но в подавляющем большинстве случаев это приведет лишь к неоправданному навешиванию на представление лишней логики.
4. При изменении модели у медиатора в классическом MVP ровно столько же информации сколько и у презентера, следовательно он так же в состоянии обновить только ту часть представления, которая необходима. Это я писал уже непосредственно тебе.

A>Понятно, что объект Point слишком мал и пример выглядит странно, но представьте себе что у нас более сложные композитные данные.
Болеее сложные композитные данные работают с более сложными композитными триадами, все эти случаи я уже описывал.

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

R> Предъявитель по сути должен уметь работать с несколькими представлениями, которые хотят отображать одну и ту же модель, которой управляет предъявитель.
Угу. Именно поэтому вводится обобщенный интерфейс для Представления и для вывода информации в нужном виде достаточно всего лишь реализовать этот интерфейс. В зависимости от ситуации Презентер имеет дело с конкретной реализацией этого интерфейса, но с какой именно ему совершенно все равно.

R> Поэтому все представления при инициализации сами обращается к нужному им предъявителю, соответственно имеют прямые ссылки на него.
Это плохо тем, что во-первых, вносит лишнюю логику в Пердставление. По сути логика работы с данными размазывается между Представлением и Презентером, в то время как основная цель паттерна сделать Представление как можно проще и по возможности сосредоточить всю логику отображения в презентере.
Во-вторых, появляется лишний раунд трип при обновлении Представления — сначала в Представление отсылается событие, а потом оно лезет обновляться.
В третих, это здорово уменьшает шанс повторного использования того же Представления с другим Презентером.

Ведь не случайно, даже в классическом шаблоне именно контроллер знает о представлении, но не наоборот.

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

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

A>>Я боялся, что простота данных введёт в заблеждение. Вобщем-то у меня нету никакого SetBoth.
R>Если нет, то и в случае MVC, и в случае MVP одно и тоже

Не будет. представление в процессе самостоятельного считывания данных может себя не перерисовывать.

R>эти сотые доли секунд

Грубая ошибка. Сложное представление может обновлятся за времена порядка секунд. Я работал с географическими картами, так там DirectX/OpenGL пришлось задействовать, а иначе ужас какая скорость 0.3-0.5 FPS.

R>И опять же вопрос: где тут разница, якобы на основании которой вы ставите MVC выше MVP?

Разница видна из комментариев выше.

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

IB>1. От того, что нет оповещений ничуть сложнее не стало — изменения в модель попадают через презентер, значит он знает, что изменения были внесены и совершенно спокойно может обновить представление, я писал об этом уже несколько раз.

Обновить — да, обновить эффективно — гораздо сложнее.

IB>2. Опять-таки я несколько раз упоминал о том, что Представление не бязательно должно работать с примитивными типами, если очень нужно то в интерфейсе вполне может быть описан метод SetPoint(Point p), хотя это и усложнит view.

Дело не в том, что это усложнит View. Дело в том, что при наличии 5-6 компонент всех вариаций методов ты просто не напишешь.

IB>3. В MVP вполне могут быть оповещения представлений моделью, о чем опять-же сказано в статье, но в подавляющем большинстве случаев это приведет лишь к неоправданному навешиванию на представление лишней логики.

Так уж и неправданному? ООД должен ускоряя разработку программы не слишком тормозить исполнение.

IB>4. При изменении модели у медиатора в классическом MVP ровно столько же информации сколько и у презентера, следовательно он так же в состоянии обновить только ту часть представления, которая необходима. Это я писал уже непосредственно тебе.

Когда я говорю об изменении необходимой части представления я имею ввиду не передачу в представление diff(old, new), а тот факт что представление может использовать только часть модели.
Например у меня есть модель — географически даные. MapView рисует карту (Bitmap), а на ней города (List<Town>) и пути по которым двигались автомобили и есть TownsView который выводит в столбик список городов. Если изменились пути движения автомобилей, то TownsView на это глубоко наплевать. И уж точно не стоит передавать туда новые пути.

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

A>Покажи мне реализацию обновления сложной модели без BeginUpdate/EndUpdate. Я тут про точку рядом написал.
Вот я тебе там и ответил. Плюс, еще есть вариант с Refresh-ем, и это если не вспоминать о том, что "не согласованное" обновление на самом деле не проблема.

A>Он обобщённый потому что интерфейс который реализуют все виды.
Да не все, а только те, которые работают с определенным набором данных. Презентер вполне может работать с несколькими IView для разных данных и с моделью могут иметь дело несколько презентеров для разных задачь...
Это не очевидно?
Ром, если бы ты свои вопросы оформлял не в виде наездов, то я бы объяснил все гораздо раньше и подробнее, а то только по косвенным признакам приходится вылавливать в чем ты не разобрался...

A>Например считывать из модели по мере необходимости.
И что тебе мешает делать то же самое в MVP?

A>View изменился?! Мда, приехали. Я такой бред никогда не нёс.
Так у тебя и View еще никогда не меняется? А данные ты как редактируешь?

A>Затем что ты не знаешь заранее какие данные нужны конкретному View.
Почему?

A>Потому что это Синглтон
Ответ неверный.

A>Я не запутался.
Запутался.

A> Вот о таком расширенном я и говорю.
Ага, Ок. Я просто думал, что это ты о своей хитрой реализации..

A> С чего это тебе именно сегодня вдруг стал непонятен термин расширеный синглтон?
Да он мне никогда не был понятен, как и многие другие твои термины, типа "точки доступа". Есть просто синглтон — паттерн который позволяет контролировать число экземпляров конкретного класса.

IB>>Могу я глядя на метод, но не зная ее реализации, утверждать, что это вот одна "точку доступа", а здесь вот у нас их на самом деле несколько?
A>Нет, не можешь.
И ты здесь никакого косяка не видишь? Все нормально?

возвращать несколько экземпляров

(c) Рома.
То есть все-таки экземпляров, а не точек доступа? Я рад, что ты наконец осознал свое заблуждение, что ж, вопрос с синглтоном можно считать закрытым..

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

A>Дело не в том, что это усложнит View.
Именно в этом, если ты все-таки читал стаью..

A> Дело в том, что при наличии 5-6 компонент всех вариаций методов ты просто не напишешь.
А зачем мне писать все?

A>Так уж и неправданному?
Именно.

A> ООД должен ускоряя разработку программы не слишком тормозить исполнение.
Как ты думаешь, на сколько это затормозит?

A> И уж точно не стоит передавать туда новые пути.
Ну так и не передавай, в чем проблема-то?


Я правильно понял, что все твои претензии свелись к тому, что это будет якобы не эффективно?

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

A>>Он обобщённый потому что интерфейс который реализуют все виды.
IB>Да не все, а только те, которые работают с определенным набором данных. Презентер вполне может работать с несколькими IView для разных данных и с моделью могут иметь дело несколько презентеров для разных задачь...

Получается логику View перетащили в Presenter. Типа понизили связность, да?

A>>Например считывать из модели по мере необходимости.
IB>И что тебе мешает делать то же самое в MVP?

То что данные View не считываются, они туда запихиваются извне.

A>>View изменился?! Мда, приехали. Я такой бред никогда не нёс.
IB>Так у тебя и View еще никогда не меняется? А данные ты как редактируешь?

View не меняется сам по себе. Только при изменении модели.

A>>Затем что ты не знаешь заранее какие данные нужны конкретному View.
IB>Почему?

Потому что у тебя только интерфейс IView. Ах ну да, у тебя теперь IView1, IView2, IView3.

A>> С чего это тебе именно сегодня вдруг стал непонятен термин расширеный синглтон?
IB>Да он мне никогда не был понятен

Вот! Вот ты и проговорился

IB>>>Могу я глядя на метод, но не зная ее реализации, утверждать, что это вот одна "точку доступа", а здесь вот у нас их на самом деле несколько?
A>>Нет, не можешь.
IB>И ты здесь никакого косяка не видишь? Все нормально?

Дял меня — да.

IB>То есть все-таки экземпляров, а не точек доступа?

Похоже твоё просветление было временным.

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

A>Так уж и неправданному? ООД должен ускоряя разработку программы не слишком тормозить исполнение.

A>Например у меня есть модель — географически даные. MapView рисует карту (Bitmap), а на ней города (List<Town>) и пути по которым двигались автомобили и есть TownsView который выводит в столбик список городов. Если изменились пути движения автомобилей, то TownsView на это глубоко наплевать. И уж точно не стоит передавать туда новые пути.
Ты пристал к IView как универсальному интерфейсу который должен решить все твои проблемы, и дал ему очень сложную задачу. Так не бывает. Если с TownsView все понятно, то как MapView так и контроллеры к нему выразить в одном классе не удастся. Тут присутсвует библиотека классов. как со стороны вьюв, так и со стороны контроллеров. Вполне понятно почему нельзя делать все в одной форме. Ты потеряешь композиционность. Если ты вделаешь сразу и рисование битмапа, обработку координат и рисование машин, рисование путей — то это будет монстр похожий на мусорку. А если еще обяжут рисовать только автобусы, или только трамваи и именно в виде трамвая? Поэтому декомпозируем по тому что именно нам нужно отобразить. Это будет рисование карты, рисование пути, рисование обычной машины и рисование допустим трамвая. Рисование машины и трамвая можно было бы совместить, так как отличаются только иконкой. Но тут встает вопрос, что для трамвая нужны рельсы, а это не совсем обычный путь. Поэтому разделяем на функции обработки где нужно рисовать, и как рисовать. То есть контроллер и вьюв. Соответвсенно, где рисовать решает некоторый набор классов контроллеров который зависит от того, что мы рисуем. И что удивительно, связь между контроллерами и классами рисования можно описать элементарными интерфейсами. Допустим. Для путей (как простого для машин, так и для электричества с рельсами для трамваев) важны массив точек для интраполяции. Допустим они наследуются от IArrayPointsPainter. Для машин и трамваев важна иконка и месторасположение — ICarPointPainter. Для городов месторасположение и название ICityPainter. Для самой картинки IBitmapPainter. При этом ICityPainter нужен не только в MapView, но и TownsView. По этим интерфейсам можно работать, и самое главное, если будут введены тролейбусы — то отрисовать их можно будет с уже текущими интерфейсами, и даже типами. Другой вопрос, что с тролейбусами может быть связана несколько другая логика(так как нужны лепектрические провода). А если у нас изменились города, то вполне достаточно воспользоваться обновить только доступные интерфейсы ICityPainter. Все — рисовальщики не знают о модели, о ней знают только контроллеры. Контракты достаточно сложного решения расписаны.

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

GZ>Контракты достаточно сложного решения расписаны.

Расписно конечно классно, но ни в OpenGL, ни в DirectX, ни даже в GDI это рисование не очень-то укладывается. Композитность конечно штука неплохая, и CompositeView объединяющий несколько View в данной задаче может быть пригодился бы, но в тоже время должен быть глобальный View — владелец IDirect3DDevice, hRenderingContext, PAINTSTRUCT или чего там надо. Вобщем некоторый контекст рисования в котором надо всё раз отрисовать. На карте я не могу отдельно перерисовать города, я вынужден перерисовать всё сразу. И кстати дорисовывать в несколько циклов рисования я тоже не могу. А у списка городов не так. И эти особенности IViewMap, IViewTowns, IViewSomethingElse о которых приходится знать презентеру, потому что теперь уже ему надо хранить этот контекст и передавать его разным IView. Либо создавать ещё какого-то отдельного RenderingContextManager. Я бы не назвал это самым удачным употреблением Flyweight.
Гораздо лучше, когда IViewTowns подписывается на Towns.Changed, а IViewMap и на Towns.Changes и на Tracks.Changed и они сами решают на что подписыватся, что считывть, как и когда перерисовывать и т.д. Меньше сущностей, проще контроль.

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

[]

Со многим согласен.

>Model-View-Controller в .Net
А кто что скажет про DataBinding? Чем не контроллер...

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

A>Получается логику View перетащили в Presenter.
Именно! Дошло наконец..

A>Типа понизили связность, да?
Не типа, а понизили, только это другой вопрос, не пытайся все опять в кучу смешать..
Связность мы понизили с помощю паттерна IoC, что никак не связано с переносом логики из View в Presenter.

A>То что данные View не считываются, они туда запихиваются извне.
И чем это мешает запихивать данные во View по мере необходимости?

A>View не меняется сам по себе. Только при изменении модели.
Еще раз. Как ты собираешься узнавать о том, что пользователь отредактировал данные во view?

A>Потому что у тебя только интерфейс IView.
И? Почему это я не знаю какие данные нужны этому интерфейсу?

A>Вот! Вот ты и проговорился
Разьве? Я никогда и не скрывал, что мне непонятны твои термины, уж слишком они отличаются от общепринятых..

IB>>И ты здесь никакого косяка не видишь? Все нормально?
A>Дял меня — да.
Тогда пожалуйста, не пытайся трактовать хорошо известные паттерны, тем более с такими новаторскими идеями — не оценят...
По крайней мере, до тех пор пока не подгонишь свою систему терминов к общепринятой.. )

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

A>Расписно конечно классно, но ни в OpenGL, ни в DirectX, ни даже в GDI это рисование не очень-то укладывается. Композитность конечно штука неплохая, и CompositeView объединяющий несколько View в данной задаче может быть пригодился бы, но в тоже время должен быть глобальный View — владелец IDirect3DDevice, hRenderingContext, PAINTSTRUCT или чего там надо. Вобщем некоторый контекст рисования в котором надо всё раз отрисовать. На карте я не могу отдельно перерисовать города, я вынужден перерисовать всё сразу. И кстати дорисовывать в несколько циклов рисования я тоже не могу. А у списка городов не так. И эти особенности IViewMap, IViewTowns, IViewSomethingElse о которых приходится знать презентеру, потому что теперь уже ему надо хранить этот контекст и передавать его разным IView. Либо создавать ещё какого-то отдельного RenderingContextManager. Я бы не назвал это самым удачным употреблением Flyweight.
И что тебе здесь не нравится? Выделения контекста вещь полезная. Поскольку в ней можно держать достаточно много простых хелперных функций. Например определения принадлежности координат региону.
A>Гораздо лучше, когда IViewTowns подписывается на Towns.Changed, а IViewMap и на Towns.Changes и на Tracks.Changed и они сами решают на что подписыватся, что считывть, как и когда перерисовывать и т.д. Меньше сущностей, проще контроль.
Не всегда это есть верно. Даже скажу больше, чаще не верно. Чем меньше повторного кода, тем лучше контроль. Для уменьшения повторного кода нужна декомпозиция. А поскольку существует(а чаще всего неоправданная) боязнь сущностей, то так и появляется мусорка кода которую рефакторить принципиально невозмножно (как и определить чем эта мусорка в тот или иной момент занимается). Каждая программная сущность должна выполнять строго определенную задачу. И если четко выполнять данное предписание, то при рефакторинга ты получишь и MCV/MCP и другие паттерны. Но самое главное применение того или иного паттерна будет всегда оправданным.

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

A>>Получается логику View перетащили в Presenter.
IB>Именно! Дошло наконец..

Что значит дошло? Это-то понятно, просто мне это очень не нравится

IB>Связность мы понизили с помощю паттерна IoC, что никак не связано с переносом логики из View в Presenter.

Связность это не только Type Declaration References. Теперь Presenter знает о View многие интимные подробности, которые никак не описываются через интерфейс IView.

A>>То что данные View не считываются, они туда запихиваются извне.
IB>И чем это мешает запихивать данные во View по мере необходимости?

Тем что View могут быть некоторые данные просто не нужны. Типичный случай — Virtual List View. Там данные могут вообще динамически подгружатся из БД, кешироватся и проч. Presenter это просто не потянет, это задача Model и View.

A>>View не меняется сам по себе. Только при изменении модели.
IB>Еще раз. Как ты собираешься узнавать о том, что пользователь отредактировал данные во view?

Иван, неужели тебе не известно, что данные во View не редактируются?! Нельзя так смешить, совсем нельзя.
Вот цепочка вызов для EditBox
EditBoxControl.OnKeyDown->EditBoxController.OnKeyDown->EditBoxModel.InsertChar->EditBoxModel.ValueChanged->EditBoxView.OnValueChanged->EditBoxControl.Refresh()

A>>Потому что у тебя только интерфейс IView.
IB>И? Почему это я не знаю какие данные нужны этому интерфейсу?

Потому что он обобщённый Удивительно как ты умудряешься непонимать простейшие вещи. Возьмём Virtual ListView. Он может хранить до миллиарда строк. Такой объём данных в памяти просто не поместится. Куда правильнее, да чего уж там, единственный возможный вариант, это когда ListView запрашивает часть данных необходимых для визуализации. причём никто кроме ListView не знает какая именно частть нужна. Эту логику в какой-то внешний Presenter ты просто не вынесешь.

IB>>>И ты здесь никакого косяка не видишь? Все нормально?
A>>Дял меня — да.
IB>Тогда пожалуйста, не пытайся трактовать хорошо известные паттерны, тем более с такими новаторскими идеями — не оценят...
IB>По крайней мере, до тех пор пока не подгонишь свою систему терминов к общепринятой.. )

У тебя просто проблемы с воображением. Наверное, тебя тебя поражает, что точка пересечений ножей гильотины может двигатся быстрее скорости света, да и другие нематериальные абстракции.

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

GZ>И что тебе здесь не нравится? Выделения контекста вещь полезная.

Да, когда он выделяется. А когда мы разбиваем один объект на кучу более мелких, потому что "так сказал пророк", получая в результате пролему их взаимодействия, то надо не контекст выделять, а менять дизайн.

A>>Гораздо лучше, когда IViewTowns подписывается на Towns.Changed, а IViewMap и на Towns.Changes и на Tracks.Changed и они сами решают на что подписыватся, что считывть, как и когда перерисовывать и т.д. Меньше сущностей, проще контроль.

GZ>Не всегда это есть верно. Даже скажу больше, чаще не верно. Чем меньше повторного кода, тем лучше контроль.

А тут не будет повторяющегося кода Карта рисуется OpenGL, список городов это ListView.

GZ>Для уменьшения повторного кода нужна декомпозиция.

Я бы сказал "удачная декомпозиция"

GZ>А поскольку существует (а чаще всего неоправданная) боязнь сущностей, то так и появляется мусорка кода которую рефакторить принципиально невозмножно (как и определить чем эта мусорка в тот или иной момент занимается). Каждая программная сущность должна выполнять строго определенную задачу. И если четко выполнять данное предписание, то при рефакторинга ты получишь и MCV/MCP и другие паттерны. Но самое главное применение того или иного паттерна будет всегда оправданным.

+1. MVC тоже навязывает абстрактные сущности Controller и View, которые очень просто объединить в Control.

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

>>Model-View-Controller в .Net
А>А кто что скажет про DataBinding? Чем не контроллер...

Очень интересно с какой точки зрения это так выглядит Можно по-подробнее?

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

A> Это-то понятно, просто мне это очень не нравится
Твое право.. Почему сделано именно так — я описал.

A> Теперь Presenter знает о View многие интимные подробности, которые никак не описываются через интерфейс IView.
Каким образом и с чего ты это взял? Опять не разобрамшись критиковать лезешь?
Presenter по определению не может ничего знать о View кроме интерфейса, именно для этого интерфейс и вводится, чтобы Presenter не знал никаких подробностей о View.
Ты не учишься, даже когда тебе ссылки под нос подкладывают.

A>Тем что View могут быть некоторые данные просто не нужны.
Ну и? Если не нужны, значит они туда не будут поставляться, в чем проблема-то?

A> Presenter это просто не потянет, это задача Model и View.
Presenter это тянет в лучшем виде, не фантазируй..

A>Иван, неужели тебе не известно, что данные во View не редактируются?!
Ну расскажи мне, как называется то место, где пользователь вводит данные

A> Нельзя так смешить, совсем нельзя. Вот цепочка вызов для EditBox
Ты прав..
Если кто-то не в состоянии абстрагироваться от конкретной цепочки вызовов, а туда же — в архитекторы лезет, это уже даже не смешно..

A>Потому что он обобщённый
Я тебе уже показал, что это не так.. Если не дошло, можешь перечитать..

A> Удивительно как ты умудряешься непонимать простейшие вещи.
Прости, Ром, но как уже неоднократно можно было убедиться, твоя логика не может быть простой.. Куда уж нам, рядовым архитектам в ней разобраться, если даже ты сам путаешься..

A> причём никто кроме ListView не знает какая именно частть нужна.
С чего ты взял, что никто?

A> Эту логику в какой-то внешний Presenter ты просто не вынесешь.
Она туда великолепно выносится, вот это-то ка краз и должно быть очевидно.

Ром, в последний раз прошу — разберись с паттерном, а не придумывай придирки на ходу. Или задавай вопросы, если что непонятно, я отвечу.

A>У тебя просто проблемы с воображением.
Доктор, а таблеток не дадите? Конечно, если ты не можешь оперировать общепринятыми терминами, разобраться как работает пара не самых сложных на свете паттернов, и внятно объяснить что ты имеешь ввиду, то естественно, в этом виновато мое воображение..

A> Наверное, тебя тебя поражает, что точка пересечений ножей гильотины может двигатся быстрее скорости света, да и другие нематериальные абстракции.
Хех, Ром.. Если бы тебя этот факт не поражал, то ты бы не привел его в качестве примера, догадывашься к чему я клоню?

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

IB>Presenter по определению не может ничего знать о View кроме интерфейса, именно для этого интерфейс и вводится, чтобы Presenter не знал никаких подробностей о View.

Ещё раз специально для тебя — связность это не только type declaration referencing.

A>>Тем что View могут быть некоторые данные просто не нужны.
IB>Ну и? Если не нужны, значит они туда не будут поставляться, в чем проблема-то?

Ну а кто решит, что их туда не надо поставлять? Presenter. А как? На основе той информации, которая IView не описывается, но тем не менее существует и повышает связность.

IB>Если кто-то не в состоянии абстрагироваться от конкретной цепочки вызовов, а туда же — в архитекторы лезет, это уже даже не смешно..

Я как раз в состоянии, я тебе просто разжевал очевидну вешь, чтобы ты не нёс чушь, будто бы View редактируется. Судя по всему зря разжёвывал, не помогло.

IB>Куда уж нам, рядовым архитектам в ней разобраться, если даже ты сам путаешься..

Я путаюсь? У тебя тут View редактируеся, куда уж мне до тебя.

A>> причём никто кроме ListView не знает какая именно частть нужна.
IB>С чего ты взял, что никто?
A>> Эту логику в какой-то внешний Presenter ты просто не вынесешь.
IB>Она туда великолепно выносится, вот это-то ка краз и должно быть очевидно.

Такс, вот ты и попался великий теоритек. Реализацию в студию. И желательно без прыжков в сторону.

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

ИБ>Авторы:
ИБ> Иван Бодягин

Прочитал статью, очень понравилась. После прочтения сразу захотелось переписать существующее приложение, благо есть время и желание. Но после просмотра примера, который идет со статьей, возник вопрос. Как происходит взаимодействие, если у нас несколько пар presenter/view? В каком месте они должны создаваться, и кем? Для примера, возмем простое приложение, реализующее функции адресной книги. Есть главная форма, предназначенная для отображение групп и контактов, есть еще несколько форм, предназначенных для редактирования/добавления групп и контактов, и, возможно, еще несколько форм для редактирования некоторых свойств группы или контакта. Как в таком случае реализуется архитектура? Как я предполагаю, для каждой формы необходимо создание пары Presenter/View, и это создание должно происходить в presenterе главной формы. Еще в форуме было предложено для этой цели использовать Factory. И должны ли presenterы знать друг о друге, или же достаточно будет реализовать паттерн с активной моделью, которая сама будет оповещать Views

Заранее спасибо за помощь в разъяснении данного вопроса.

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

A>Не будет. представление в процессе самостоятельного считывания данных может себя не перерисовывать.
Почему вы решили, что MVP обязывает представление перерисовываться без какой-либо самостоятельной логики? Если так в примере автора, то это же еще ни о чем не говорит: указали направление, а конкретика реализации — ваше творчество.

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

IB>Угу. Именно поэтому вводится обобщенный интерфейс для Представления и для вывода информации в нужном виде достаточно всего лишь реализовать этот интерфейс. В зависимости от ситуации Презентер имеет дело с конкретной реализацией этого интерфейса, но с какой именно ему совершенно все равно.
Наверно не очень подробно описал. Принципиального различия в работе предъявителя с представлениями нет: у вас предъявитель работает с интерфейсом IView, а в моем варианте в рамках шаблона проектирования Observer, к примеру, с интерфейсом ISubscriber, то есть интерфейсом подписки представления на события предъявителя — особенной разницы нет.

Просто в вашем примере не очень понятно, как несколько представлений будут работать с одной моделью-предъявителем, а как иначе, нежели как через Observer, где предъявитель является публикатором? Хотя вру... вы, кажется, писали, что в рамках MVP можно оставить активную модель, то несколько представлений подпишутся, как и в MVC, на события одной модели. Но ведь это сложнее: усложняется модель и представление — нежели сделать предъявитель публикатором.

IB>Это плохо тем, что во-первых, вносит лишнюю логику в Пердставление. По сути логика работы с данными размазывается между Представлением и Презентером, в то время как основная цель паттерна сделать Представление как можно проще и по возможности сосредоточить всю логику отображения в презентере.
IB>В третих, это здорово уменьшает шанс повторного использования того же Представления с другим Презентером.
С другой стороны, как работает представление с предъявителем... Это опять же интерфейс по шаблону проектирования Command, к примеру, ICommand. То есть представление тоже не сильно связано с предъявителем — оно может быть спокойно перекинуто на другой предъявитель, который реализует интерфейс Command.

Согласен, что часть логики все же переходит в представление. Но... здесь я соглашусь с adontz, который справедливо указывает на накладные расходы при прорисовке графических форм представлений, если последние полностью лишены логики перерисовки. Мне все же удобнее оставить представление чуточку "умным", понимаю, что тестирование его при этом усложнится.

IB>Во-вторых, появляется лишний раунд трип при обновлении Представления — сначала в Представление отсылается событие, а потом оно лезет обновляться.
Отчего? Почти как и у вас: в событии предъявитель шлет представлению данные для обновления — представление абсолютно ничего не знает о модели, не знает, где ее искать, все только через предъявитель.

IB>Ведь не случайно, даже в классическом шаблоне именно контроллер знает о представлении, но не наоборот.
Вот и не пойму, как в классике предполагается работа нескольких представлений с одной моделью.

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

Y> Как я предполагаю, для каждой формы необходимо создание пары Presenter/View, и это создание должно происходить в presenterе главной формы.
Представление для каждой формы — возможно, а вот предъявитель, как понимаю, ни в коем случае, потому что форма, а значит представление должно уметь работать с несколькими предъявителями, чтобы отображать одну и ту же модель — это постоянно встающая задача графических приложений.

Y> Еще в форуме было предложено для этой цели использовать Factory.
Возможно вы забыли...
Я не предлагал фабрикой создавать пары предъявитель-представление, а только предъявители. Представление может инициализировать, в принципе, и сама форма. Возможно есть такие задача, но сам не сталкивался, когда необходимо, чтобы несколько форм отображали одно и то же представление — то есть фабрики представлений вроде бы как и не нужно.

Y> И должны ли presenterы знать друг о друге, или же достаточно будет реализовать паттерн с активной моделью, которая сама будет оповещать Views
Здесь

Автор: rsn81
Дата: 07.11.06

описал свое предложение, но как и вы хотел бы услышать мнение автора.

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

Y>> Еще в форуме было предложено для этой цели использовать Factory.
R>Возможно вы забыли...
R>Я не предлагал фабрикой создавать пары предъявитель-представление, а только предъявители. Представление может инициализировать, в принципе, и сама форма. Возможно есть такие задача, но сам не сталкивался, когда необходимо, чтобы несколько форм отображали одно и то же представление — то есть фабрики представлений вроде бы как и не нужно.

Спасибо, что разьяснили, я и вправду не до конца понял, поэтому и спрашиваю.

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

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

>>>Model-View-Controller в .Net
А>>А кто что скажет про DataBinding? Чем не контроллер...

A>Очень интересно с какой точки зрения это так выглядит Можно по-подробнее?

Хм не совсем контроллер больше на презентера похож
задача презентера связать данные от моджели с видом и далее от вида передать данные в
модель, по моему датабиндинг с этим вполне себе справляется. или же я что то не учел?

Здравствуйте, Иван Бодягин, Вы писали:

Вопрос по архитектуре... Вы где-то в теме говорили, кажется, что в принципе нужно, чтобы представление могло работать с несколькими моделями.

Варианты:

1. Как всегда делал. Такое представление просто будет композитом, состоящим из нескольких представлений, каждое из которых работает со своей моделью, в рамках концепции MVP — со своим предъявителем. Это не исключает возможность работы нескольких представлений с одним предъявителем. Итого: связка "много представлений — один предъявитель".

2. Сделать иначе. То есть будет сложная связка "много представлений — много предъявителей", и в ту и в другую сторону идут оповещения по шаблону проектирования Observer:
— связка "один предъявитель — много представлений": предъявитель оповещает все представления пописавшиеся на события об изменении модели, то есть какое-то представление скомандовало изменить модель, а другие представления также получили оповещение после изменения модели;
— связка "одно представление — много предъявителей": представление может оповещать (командовать на изменение модели) всем предъявителям, которые принудительно были самим представлением подписаны на прием от него команд.

Мне вот все кажется, что вариант 2 сложный. Зачем городить архитектурное решение там, где можно все решить обычным наследованием и инкапсуляцией (вариант 1). Может я что-то не учел?

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

R> Принципиального различия в работе предъявителя с представлениями нет:
Ну как в одном случае связь развернута в одну сторону, в другом — в другую, вот это и есть принципиальнео различие..

R>Просто в вашем примере не очень понятно, как несколько представлений будут работать с одной моделью-предъявителем,
Непонятно с какой конкретной реализацией Представления работает Перзентер или непонятно как Презентер работает с несколькими представлениями? И что именно непонятно?

R> а как иначе, нежели как через Observer, где предъявитель является публикатором?
Просто развернуть связь в обратную сторону. Презентер имеет прямую ссылку на все активные представления, и является подписчиком на события в этих представлениях возникающие.

R> Но... здесь я соглашусь с adontz, который справедливо указывает на накладные расходы при прорисовке графических форм представлений, если последние полностью лишены логики перерисовки.
На накладные расходы при перерисовке он указывает совершенно не справедливо, но даже если и так то, во-первых, как часто вам приходится писать графические редакторы и прочие Представления критичные именно к скорости отображения? А во-вторых, ничто не мешает передать критичный к скорости отображения объект целиком.

R> Мне все же удобнее оставить представление чуточку "умным", понимаю, что тестирование его при этом усложнится.
Это на усмотрение.. В каждом конкретном случае гранулярность отображаемых данных оперделяется исходя из задачи.

R>Отчего?
От того что связ развернута в другую сторону. В этом случае вообще получается, что View меняет модель, Presenter — практически Pass-thru объект, который транслирует вызовы View в изменение модели, после чего через событие-же дает View на отрисовку.

R>Вот и не пойму, как в классике предполагается работа нескольких представлений с одной моделью.
А что непонятного? Презентер является фабрикой для View и имеет ссылки на все активные Представления. Как только в представлении происходит событие, Презентер соответствующим образом изменяет модель и дает нужным представлениям команду на перерисовку.

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

A>Ещё раз специально для тебя — связность это не только type declaration referencing.
Еще раз, специально для тебя.. Презентер ничего не знает о представлении кроме интерфейса. Ну что ты придирки из пальца выжимаешь, заняться нечем?

A>На основе той информации, которая IView не описывается, но тем не менее существует и повышает связность.
Ну вот откуда ты взял, что эта информация в IView не описывается?
Понимаешь, проблема в том, что ты представил себе какую-то модель в голове и пытаешься паттерн под нее подогнать, а делать надо ровно наоборот.

A>Такс, вот ты и попался великий теоритек. Реализацию в студию. И желательно без прыжков в сторону.
Ром, прыжками в сторону занимаешься исключительно ты — половину проигнорировал, все претензии свелись к "эффективности". Ну ей богу, если бы ты просто спрашивал, а не наезжал, то и глупостей меньше наговорил бы, и разобрались бы существенно быстрее.
Вот скажи мне, великий практик, что мешает Представлению, пользуясь явным контрактом IView сообщить Презентеру, какая именно порция данных нужна ему в данный момент?

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

Y> Как происходит взаимодействие, если у нас несколько пар presenter/view?
По разному, вариантов действительно много...

Y>В каком месте они должны создаваться, и кем?
Как правило, в простейших случаях с одним презентером, либо используется отдельная фабрика для View, либо сам Презентер/Контроллер является фабрикой для View. Если же мы имеем дело с более сложной конструкцией, опять-таки используется отдельная фабрика для построения триад нижнего уровня. Но это уже несколько выходит за рамки чистого MVP/MVC, здесь надо уже подключать паттерны для выстраивания иерархии приложения — совершенно отдельная тема для разговора

Y> Есть главная форма, предназначенная для отображение групп и контактов, есть еще несколько форм, предназначенных для редактирования/добавления групп и контактов, и, возможно, еще несколько форм для редактирования некоторых свойств группы или контакта. Как в таком случае реализуется архитектура?
В простейшем случае можно выделить один Presenter, который обращается к фабрике View с указанием экземпляр какого интерфейса нужен и работает дальше с ним... Однако при росте приложения это приведет к тому, что презентер будет перегружен совершенно разноплановой логикой и рано или поздно придется выделять отдельные триады, на каждую форму или группу форм (или вообще в самостоятельную триаду MVP может быть выделен каждый контрол). Эти триады могут быть связаны между собой с помощю триад более высокого уровня причем связь может быть осуществлена как строго через презентер, так и через другие элементы триады — смотрите по ссылкам в статье на паттерны HMVC и PAC.

Y> Как я предполагаю, для каждой формы необходимо создание пары Presenter/View, и это создание должно происходить в presenterе главной формы.
Да, это один из вариантов.

Y> И должны ли presenterы знать друг о друге, или же достаточно будет реализовать паттерн с активной моделью, которая сама будет оповещать Views
А как больше нравится.. В своих приложениях я предпочитаю вариант с пассивной моделью и как можно более плоским View, но в конкретной ситуации вполне может оказаться удобнее сделать активную модель.
Поиграйтесь, хоть с тем же справочником, попробуйте разные варианты, посмотрите как удобнее..

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

R>Вопрос по архитектуре... Вы где-то в теме говорили, кажется, что в принципе нужно, чтобы представление могло работать с несколькими моделями.
Не с моделями, а с Презентерами... Работаь View с несколькими моделями — проблематично, в этом случае модели должны соответствовать некоторому контракту, что естественно накладывает на модель определенного рода ограничения.
Да и нужно это не всегда. Вот если у нас View представляет собой контрол, то его переиспользование с несколькими презентерами — одно из основных требований, если же View — достаточно развесистая форма, то переиспользование ее в другой ситуации вряд ли потребуется.
Сама же возможность переиспользования заложена в четком описании контракта для View.

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

А>Основное, что не понравилось — дикие тормоза при загрузке/открытии форм, ибо все
А>создание объектов происходит через рефлекшн. Особенно если использовать контролы,
А>насыщеные графикой (DevExpress в частности) — форма грузится 1.5-2 сек на AthlonXP 1700+ 256Mb RAM

Это не проблемы CAB, это проблемы конкретно DevExpress. Особенно грид там больной. Можешь погонять под профайлером.

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

AI>Неужели никто не делает корректуру перед публикацией?

Корректуру делают, но на сайт могла попасть неоткорректированная версия.

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

IB>Ну как в одном случае связь развернута в одну сторону, в другом — в другую, вот это и есть принципиальнео различие..
Ага, это уже почуял.

IB>Непонятно с какой конкретной реализацией Представления работает Перзентер или непонятно как Презентер работает с несколькими представлениями? И что именно непонятно?
Прочитав ответы ниже, все понял.

IB>Просто развернуть связь в обратную сторону. Презентер имеет прямую ссылку на все активные представления, и является подписчиком на события в этих представлениях возникающие.
Понято, просто мне хочется понять, уступает ли мое представление картины в чем-то вашему или нет.

IB>На накладные расходы при перерисовке он указывает совершенно не справедливо, но даже если и так то, во-первых, как часто вам приходится писать графические редакторы и прочие Представления критичные именно к скорости отображения? А во-вторых, ничто не мешает передать критичный к скорости отображения объект целиком.
Да, можно считать это просто придиркой, в целом это копейки. Разумеется, видеоадаптер не стоит проектировать на основе MVC, а выводить напрямую — для всего свое назначение.

IB>От того что связ развернута в другую сторону. В этом случае вообще получается, что View меняет модель, Presenter — практически Pass-thru объект, который транслирует вызовы View в изменение модели, после чего через событие-же дает View на отрисовку.
Транслирование вызовов View в изменение модели — это Command, по сути тоже обобщенный интерфейс. У вас в этом месте Observer с событиями, в этом и "развертывание в другую сторону", насколько представляю. Я решил не делать Observer при общении представления с предъявителем, потому что этот шаблон ориентирован на общение "одного с многими" (публикатора с подписчиками), а я не встречал пока необходимости общения одного представления с несколькими предъявителями (моделями), об этом написал выше отдельный вопрос вам. Зато вот общение одного предъявителями с несколькими представлениями, которые отображают одну модель, у меня по Observer. У вас в примере это не продемонстрировано (там одно представление только), но в реалии вы же наверно тоже по Observer оповещаете представления?

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

IB>Не с моделями, а с Презентерами...
Ага, для меня это уже транзитивно, забываю иногда.

IB> Вот если у нас View представляет собой контрол, то его переиспользование с несколькими презентерами — одно из основных требований
Угу, осталось дождаться вашего ответа на вопрос здесь

Автор: rsn81
Дата: 08.11.06

о том, как именно вы видите эту связку... то есть тоже по Observer?

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

A>Да, когда он выделяется. А когда мы разбиваем один объект на кучу более мелких, потому что "так сказал пророк", получая в результате пролему их взаимодействия, то надо не контекст выделять, а менять дизайн.
Нет. Я взял гипотетическую задачу предложенную тобой, гипотетически помыслил и привел логику получения гипотетического решения на основе представленных тобой данных, и на предположении что количество отображаемых сущностей может изменяться. В свете артефактов предоставленных тобой и данного предположения задача решается данным паттерном как родная. При этом я не учитывал артефакты о которых я не знаю, и соответвенно как сделать данную задачу в жизни или есть лучшие решения точно сказать нельзя.
Проблемы взаимодействия я здесь не вижу. Вижу только ее решение.
1. Модель абсолютно пассивна и плохо представляет для чего ее пользуют. Ее задача предоставить данные. Представления полностью изолированы от модели, и соответвенно любое изменение модели не отражается на рисовалках. Как собственно верно и обратное утверждение.
2. Добавление новой отображаемой сущности упрощается.
2.1 Если сущность должна отображаться уникально, то велика вероятность что она может быть описана уже готовым интерфейсом, как то (координаты, название), (путь), (координаты, иконка). То есть, остается реализовать только класс рисовалку поддерживающий данный интерфейс. Контроллер ведь оперирует только интерфейсом.
2.2 Если есть уже готовая рисовалка но при обработке информации есть изменения, то наша задача ограничется только созданием нового контроллера.
3. Достаточно легко строить новые формы на основе уже существующих кирпичей.
4. Система тестируема. Мы не можем автоматизировано построить проверку как работают контроллеры. И мы можем раздельно проверить как рисуются рисовалки.


A>А тут не будет повторяющегося кода Карта рисуется OpenGL, список городов это ListView.
Oops. Только что это был DirectX. Хотя это однокомпозиционно, поскольку вывод зависит только от рисовалок. Можно сделать рисовалки, которые рисуют в DirectX, OpenGL, в формы или в log в виде тупого текста. Ни модель, ни контроллеры от этого практически не меняются. (хотя в контроллерах я допускаю что возможна некоторая несущественная зависимость.) И контекст вывода является пререгативой рисовалок а не контроллеров. Посему возможно контроллерам о нем и знать то не надо.

A>+1. MVC тоже навязывает абстрактные сущности Controller и View, которые очень просто объединить в Control.
Но тогда это уже не будет MVC.

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

A>Но почему этот класс не может делегировать рисование одному классу (кстати уже так и есть, поглядите классы *Renderer)

Это совсем из другой оперы.

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

A>>Такс, вот ты и попался великий теоритек. Реализацию в студию. И желательно без прыжков в сторону.
IB>Ром, прыжками в сторону занимаешься исключительно ты — половину проигнорировал, все претензии свелись к "эффективности". Ну ей богу, если бы ты просто спрашивал, а не наезжал, то и глупостей меньше наговорил бы, и разобрались бы существенно быстрее.

То есть пример ты привести не можешь. Так и запишем.

IB>Вот скажи мне, великий практик, что мешает Представлению, пользуясь явным контрактом IView сообщить Презентеру, какая именно порция данных нужна ему в данный момент?

Теоретически ничего не мешает. Просто раньше этого не надо было делать, а следовательно налицо усложнение программы на пустом месте. Оно мне не надо.

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

R> У вас в примере это не продемонстрировано (там одно представление только), но в реалии вы же наверно тоже по Observer оповещаете представления?
Зачем? У Презентера есть прямая ссылка на все активные Представления, Observer здесь просто не нужен, а вот View оповещает о происходящих в нем изменениях Презентер именно через Observer.

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

IB>Зачем? У Презентера есть прямая ссылка на все активные Представления, Observer здесь просто не нужен, а вот View оповещает о происходящих в нем изменениях Презентер именно через Observer.
Все, дошло.
Понял ваше видение, но все же пойду другим путем, который описывал выше.

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

A>То есть пример ты привести не можешь.
Я описал как это выглядит, что, тебе по прежнему что-то непонятно? Я не злопамятный, могу объяснить — ты только спрашивай..

A>Теоретически ничего не мешает.
Значит возражение снимается и никакой мифической связности больше нет? Отлично.

A>Просто раньше этого не надо было делать
Надо. Раньше эта логика была во View, теперь в презентере, ее в любом случае надо реализовывать.

A>, а следовательно налицо усложнение программы на пустом месте.
Надо признать, что палец из которого ты высасываешь претензии к паттерну изрядно поистощился.. Может хватит?

A>Оно мне не надо.
Байта ради, я не настаиваю..

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

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

A>>То есть пример ты привести не можешь.
IB>Я описал как это выглядит, что, тебе по прежнему что-то непонятно? Я не злопамятный, могу объяснить — ты только спрашивай..

То есть пример ты привести не можешь. Так и запишем — теоретик.

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

A>То есть пример ты привести не можешь.
Могу, только не вижу смысла или тебе все-таки что-то непонятно? Или это все к чему ты в итоге можешь придраться?
Эх, слабоват нонче критик пошел.. =)

A> Так и запишем — теоретик.
Да записывай как угодно, не тебе меня критиковать.. Тебя-то уже давно записали..

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

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

A>>То есть пример ты привести не можешь.
IB>Могу

Сильно в этом сомневаюсь. Более того, я просто хотел чтобы ты пытаясь это сделать, понял что это невозможно по независящим от тебя причинам.

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

A>Более того, я просто хотел чтобы ты пытаясь это сделать, понял что это невозможно по независящим от тебя причинам.
Опять путаешься и сам себе противоречишь?

Теоретически ничего не мешает.

(c) Рома.
Так что же это за независящие причины такие — ничто не мешает, но сделать не дает? Ты можешь их внятно сформулировать или так и будешь балобольством заниматься?

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

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

A>>Более того, я просто хотел чтобы ты пытаясь это сделать, понял что это невозможно по независящим от тебя причинам.
IB>Опять путаешься и сам себе противоречишь?
IB>

IB>Теоретически ничего не мешает.

Я так про совсем другое говорил. Нечего выдёргивать фразы из контекста.

IB>Так что же это за независящие причины такие — ничто не мешает, но сделать не дает? Ты можешь их внятно сформулировать или так и будешь балобольством заниматься?

А зачем? На слово ты мне не веришь. Пойди набей персональную шишку, тогда и поговорим. Если не через сообразительность, так хоть через старание поумнеешь. Кстати напомню задачу, есть ListViewControl в котором 100 млн записей. Записи хранятся в БД. Предлагается организовать из отображение отожрав 20-30Мб (Нк 50, совесть тоже надо иметь) ОЗУ. Ы? И чтоб объязательно MVP, а иначе не круто. Да, про сортировку не забудь.