Аннотация:
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и в месте с ними изменялся и сам паттерн. Данная статья посвящена так же одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, перимуществам и недостаткам, а так же описанию сопутствующих паттернов.
ИБ>Авторы: ИБ> Иван Бодягин
ИБ>Аннотация: ИБ>В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и в месте с ними изменялся и сам паттерн. Данная статья посвящена так же одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, перимуществам и недостаткам, а так же описанию сопутствующих паттернов.
Дело описывать такие паттерны дело не благодарное (так и знал что минусов наставят и оценка низкая будет)
Здравствуйте, <Аноним>, Вы писали:
А>так и знал что минусов наставят и оценка низкая будет
Меня другое интересует, за что минусы — за статью или за аннотацию?..
А>Хотя спасибо за попытку
Да пожалуйста... Вообще статья планиировалась несколько болше с разбором более сложных случаев, иерархических версий паттерна, ect., но поджимали сроки, последние правки вбивались практически перед отправкой номера в печать..
Немного критики:
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 значительно упрощает дальнейшую разработку на его основе.
Ну, это уже ортогональный аспект, все зависит от конкретной задачи, иногда действительно удобно использовать подобную параметризацию, но на суть паттерна это не влияет.
Понятно. Чтобы говорить предметно, нужно все же ознакомиться с материалом. Ушел на поиски номера журнала.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[8]: Код к статье
От:
Аноним
Дата:
08.08.06 02:03
Оценка:
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, IB, Вы писали:
R>Понятно. Чтобы говорить предметно, нужно все же ознакомиться с материалом. Ушел на поиски номера журнала.
Классический шаблон MVC описан на удивление доходчиво. На удивление — это ирония отнюдь не в сторону способностей автора доходчиво доносить свои мысли читателю, а в сторону относительной сложности объяснения необходимости использования шаблона MVC достаточно большой кагорте программистов, которые не знают другого подхода к программированию, как начинающегося с накидывания визуальных форм а-ля Delphi и тянущегося за этим действием копания собственной могилы.
Сам проектирую desktop (Java, C#) и web-системы (C# ASP.NET) на основе именно классического шаблона MVC. Потому модификация шаблона MVP не могла не заинтересовать.
Отметил следующие несомненные достоинства MVP по отношению к MVC:
1. Представление получается легким, что скорее всего действительно позволит покрыть тестами большую область проекта и в большей мере избавиться от тестирования и отладки визуальных объектов, чем в MVC. Там это действительно головная боль.
2. Взаимодействие в системе MVP получается более простым, чем в MVC, где имеет место замкнутое кольцо: при активном действии пользователя, к примеру, представление дергает контроллер, который изменяет модель соответствующим образом, модель в свою очередь генерирует событие о своем изменении, которое принимает представление. Событийная модель MVC, как мне кажется, относительна сложна в плане понимания, то есть при разрастании проекта на основе MVC может наступить момент, когда программист запутается во взаимосвязях. Но, в принципе, вероятность этого можно свести к минимуму, решение есть...
К недостатку MVP отнес бы следующее. Все же происходит повторение кода перекидывания данных из представления, но, насколько понял, именно за счет этого мы и получаем первое преимущество (см. выше). То есть, как мне кажется, это оправдывается с лихвой.
Если автор найдет время, интересно было бы прочитать его комментарии по поводу вышесказанного (возможно, что-то из материала понял неверно) и по поводу проектирования иерархической MVC — хотя бы в двух словах: область применения, преимущества и т.п.
Здравствуйте, rsn81, Вы писали:
R>Если автор найдет время, интересно было бы услышать его комментарии по поводу вышесказанного (возможно, что-то из материала понял неверно)
Все верно, именно это я и пытался донести, включая недостатки, представляя паттерн MVP..
R> и по поводу проектирования иерархической системы — хотя бы в двух словах: область применения, преимущества и т.п.
Ну, реальные приложения несколько сложнее, чем в примере и, как правило, они состоят из нескольких мало связаных частей. Реализация этих частей в виде самосотятельных MVC триад позволяет уменьшить между этими частями связность, повысить степень повторной используемости кода, легко реализовать расширяемость, ect... Вообщем классический набор.
Например, очень удобно реализовывать различные плагинные конструкции, когда основное приложение реализует MVP, предоставляя каркас для модулей, которые, в свою очередь, реализуют MVP, размещая свои View в предоставленых основным приложением местах, при этом сами модули могут быть родительскими поотношению к модулям более низкого уровня... Или, уже озвученная ситуация, когда для большой красивой модели требуется несколько presenter-ов, в этом случае представляется разуным ввести некую метамодель и presenter более высокого уровня, для координации взаимодействия presenter-ов и состояния модели.
К сожалению не имею возможности ознакомится со статьей, давно изучаю (и использую) МВП и убедился в его ценности, но всеже есть несколько вопросов:
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 является фабрикой для представлений, об этом есть упоминание в статье.
Здравствуйте, 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 лабы и версию под бейсик пишут вроде...
Мы уже победили, просто это еще не так заметно...
)
