dev.net.ua

В общем предлагаю рассмотреть эту статью и оставить свои впечатления :)
http://www.vsj.co.uk/dotnet/display.asp?id=449

Andrews:

В общем предлагаю рассмотреть эту статью и оставить свои впечатления :)
http://www.vsj.co.uk/dotnet/display.asp?id=449

Шивидше за все, саме про цю реалізацю Martin Fawler сказав що є багато реалізацій де його помилково зрозуміли ;).

Краще читайте http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx

це найкраще що я колись бачив, в цій статті ДЕМНОСТРУЄТЬСЯ увесь (в домашньому сенсі) процес розробки.

Моя думка: MVC занадто складний, наприклад в порівнянні з MVP, дотогож він не надає жодних перваг.

---

MCPD(Web,Windows,Enterprise), MCTS (WPF, WCF)

Mike Chaliy:

Andrews:

В общем предлагаю рассмотреть эту статью и оставить свои впечатления :)
http://www.vsj.co.uk/dotnet/display.asp?id=449

Шивидше за все, саме про цю реалізацю Martin Fawler сказав що є багато реалізацій де його помилково зрозуміли ;).

Краще читайте http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx

це найкраще що я колись бачив, в цій статті ДЕМНОСТРУЄТЬСЯ увесь (в домашньому сенсі) процес розробки.

Моя думка: MVC занадто складний, наприклад в порівнянні з MVP, дотогож він не надає жодних перваг.

Согласен, я это читал раньше - очень понравился подход. К сожалению сегодня с утра не смог найти эту ссылку

Используем в некотором роде MVC ;-)

Model - класс, отображающий структуру хранения данных (только атрибуты + свойства (приведение типов) + конструктор). Один в один соответствует табличке в БД.

Controller - класс, содержащий операции по работе с Model-классом. Оперирует экземплярами соответствующего Model-класса.

View - это ASP.NET 2.0 User Control (.ascx, .ascx.cs). Больше никаких прослоек. ObjectDataSource, работающий с Controller'ом напрямую, стандартные ASP.NET 2.0 контролы + MS AJAX. Удобно тем, что: кода мало, многое в разметке, тот код что есть, легко пишется и читается.

Как представлю себе, что в случае использования MVP, например, чтобы понять КАК отображается бизнес-класс, нужно еще лезть в другой файлик, ужас...

 

Естественно, есть DAL, который оперирует скалярными типами данных (Nullable<> two-way databinding FTW). Работает DAL с БД через MS Data Access Application Block. Есть реализованные проекты под SQL Server и под Oracle в этой архитектуре. Все замечательно и быстро работает. Где-то 80% общего объема кода генерируется по структуре БД ;-)

 

Alternate:

Используем в некотором роде MVC ;-)

Model - класс, отображающий структуру хранения данных (только атрибуты + свойства (приведение типов) + конструктор). Один в один соответствует табличке в БД.

Якщо бізнес об'єкти завжди такі самі як таблиці, то сенсу їх створювати немає. Доречі в Model це ажніяк не бізнес об'ект, згідно з Martin Fawler це може бути а шар серісів(яка може поверати об'єкти, а може як і транзакшен скріпт повертати дахолждери на кшатал DataRow), або доменна модель(яка повератє оті самі об'єкти), або транзакшен скрипт.

Alternate:

Controller - класс, содержащий операции по работе с Model-классом. Оперирует экземплярами соответствующего Model-класса.

Те саме і в MVP. Тут змінюється тільки термін, тут це називається Presenter 

Alternate:

View - это ASP.NET 2.0 User Control (.ascx, .ascx.cs). Больше никаких прослоек. ObjectDataSource, работающий с Controller'ом напрямую, стандартные ASP.NET 2.0 контролы + MS AJAX. Удобно тем, что: кода мало, многое в разметке, тот код что есть, легко пишется и читается.

За допомогою ObjectDataSource, ви аж на 20% зможете покрити тестами ваш контроллер, а більшість логіки відтворення ви навіть не побачете, бо все у вас буде декларативно...

Alternate:

Как представлю себе, что в случае использования MVP, например, чтобы понять КАК отображается бизнес-класс, нужно еще лезть в другой файлик, ужас...

Незрозумілу куди треба лізти? Як у MVC є залежність між Model і Controller, так і у MVP між Model та Presenter.

Alternate:

Естественно, есть DAL, который оперирует скалярными типами данных (Nullable<> two-way databinding FTW). Работает DAL с БД через MS Data Access Application Block. Есть реализованные проекты под SQL Server и под Oracle в этой архитектуре. Все замечательно и быстро работает. Где-то 80% общего объема кода генерируется по структуре БД ;-)

Едине що я можу сказати, це те ще MVP не відрізня.ться від MVC по кількості згенерованного коду. Зокрема MVP дає можливість гереувати покриття тестами, а ось ваш ObjectDataSource ні (це про декларативний біндінг).

---

MCPD(Web,Windows,Enterprise), MCTS (WPF, WCF)

Еще раз:

1) для модели достаточно класса, в котором хранятся значения (атрибуты) + есть приведение типов + есть например такие вещи, как Lazy Load. Добавляем ко всему этому List<MyType> и все

Смысл создания такой модели - работа в привычном объектном коде, а не с датасетами (хотя бы и типизированными)

Плюс - сериализация этих данных очень легкая. Плюс поддержка паттернов Strategy (Command) & Data Object

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

2) Теперь что касается тестирования. Да, все в разметке (UI). В .cs файле почти нет кода. И что в этом плохого ? Кто сказал, что лучший способ тестировать UI - это использование юнит-тестов на том же .NET ? Для этого используется специализированный софт, который эмулирует поведение пользователя (например, TestComplete 4.x).

3) Важное отличие в данном случае в том, что у меня разметка UI лежит там где ей положено лежать. И я могу в design-time посмотреть как будет выглядеть страничка. И это удобно. И это всегда проще для разработчиков. И еще это позволяет использовать как типовые решения (например, отображение списка - GridView, редактирование записи - FormView - и это у нас генерируется автоматически), так и вручную делать какие-то уникальные вещи. При этом, ты берешь сгенерированную разметку и вносишь какие-то изменения. И все исходники у тебя на виду - в одном файлике. А в случае с MVP ? Когда половина кода в presenter'ах, а половина в разметке (ибо так проще и быстрее, смысл выносить это в уникальный презентер класс ?) ?

 

Alternate:

1) для модели достаточно класса, в котором хранятся значения (атрибуты) + есть приведение типов + есть например такие вещи, как Lazy Load. Добавляем ко всему этому List<MyType> и все

Смысл создания такой модели - работа в привычном объектном коде, а не с датасетами (хотя бы и типизированными)

Плюс - сериализация этих данных очень легкая. Плюс поддержка паттернов Strategy (Command) & Data Object

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

Окрім Lazy Load, все це надає датасети ;), і хоча я їх теж не використовую, в більшості випадків, коли немає генерування (з будь яких причин, наприклад проект маленький),  датасети можуть стати альтернативою, принаймні вони надоють достню кількість можливостей, наприклад структуру колонок без рефлексії.

Alternate:

2) Теперь что касается тестирования. Да, все в разметке (UI). В .cs файле почти нет кода. И что в этом плохого ? Кто сказал, что лучший способ тестировать UI - это использование юнит-тестов на том же .NET ? Для этого используется специализированный софт, который эмулирует поведение пользователя (например, TestComplete 4.x).

Я ніколи не казав що це кращий спосіб, дотого ж я не казав що потрібно покривати ТІЛЬКИ юніт тестами, принаймні я вважаю що тільки декілька технологій тестування зможуть покрити все(майже все), існують такі речі як наприклад усілкого рода динамічні графіки які ви ну аж ніяк не покриєте UI скриптами. При цьому юныт тести це роблять аж на ура. А тому викидати цю можливість.. ну принаймні я вважаю що це не є тим чим я можу знехутвати...

Alternate:

3) Важное отличие в данном случае в том, что у меня разметка UI лежит там где ей положено лежать. И я могу в design-time посмотреть как будет выглядеть страничка. И это удобно. И это всегда проще для разработчиков. И еще это позволяет использовать как типовые решения (например, отображение списка - GridView, редактирование записи - FormView - и это у нас генерируется автоматически), так и вручную делать какие-то уникальные вещи. При этом, ты берешь сгенерированную разметку и вносишь какие-то изменения. И все исходники у тебя на виду - в одном файлике. А в случае с MVP ? Когда половина кода в presenter'ах, а половина в разметке (ибо так проще и быстрее, смысл выносить это в уникальный презентер класс ?) ?

В MVP все так само, у MVP є декілька послідовників, якщо ви УСЮ логіку хочете винести в презентер, будь ласка - Passive View, але це в більшості випадків для простих скрінів, якщо хочете логіку відображення залишит во вью - Supervising Controller, все залежить від того що саме ви хочете. І усе UI лежить саме там де треба. З чого це ви вирышили що в MVP не буде GridView? А от FormView швидше за все не буде, хоча це вже не обумовлено самим MVP, це швидше за все обумовлено тим що використання FormView призводить до занато збільшеної кількості декларативного коду.

Наведу приклад, в мене є сторінка де є декілька контролів які змінюють свій стан (просто показуються) якщо коистувач натиснув конпку. В цьому випадку я не бачу сенсу виносити це в презетер, а тому впереше їхній стан задаеється з презентера(якщо в цьому є необхідність), а потім вже саме віью контролює показувати чи ні.

Але це можливо тільки в тому разі, якщо ніяка бізнес логіка в цьому не задіяна, наприклад скачати/закачати файл, відкрити/закрити календар.

Якщо для чогось потрібна бізнес логіка, то це стовідсотково повинно проходити через презентер, наприклад якщо мені потрібно згенерувати інформацію якою буде заповнено форму при створенні наприклад користувача.

Що це нам дає. Відкриття/закриття панелей тестується за допомогою автоматизованих тулз, а такі речі як створення нового користувача за допомогою частково тулз, частково юніт тестів. Для того щоб первірити усі кейси (у яких є логіка заповнення) за допомогою тулзи знадобиться набагато більше часу. Але наприклад первірити що ця форма відкривається ;) краще за допомогою тулизи.

P.S. Якщо вас нервує розмова, ми її можемо припинити, я вже зрозумів вашу позицію і швидше за все ви зрозуміли мою. Просто скажіть у наступному листі, потребує ваш лист відповіді чи ні.

---

MCPD(Web,Windows,Enterprise), MCTS (WPF, WCF)

В общем вот
http://codebetter.com/blogs/jeffrey.palermo/archive/2007/03/16/Big-News-_2D00_-MVC-framework-for-ASP.NET-in-the-works-_2D00_-level-300.aspx
как показало время microsoft никогда не упускало шанса сделать что то хорошее, но по своему :)

Майк, ви не могли б порадити якусь літературу з цієї теми?

---

Artyom Krivokrisenko
Web Reflection, Development Department

Brand:

Майк, ви не могли б порадити якусь літературу з цієї теми?

Прикро, але схоже що ні. Покищо мої знання більше з досвіду, прегляду референс реалзіцій та статтей. Едина книга з цього приводу яку я заню це Martin Fowler - Patterns of Enterprise Application Architecture. Але в цій книзі усе закінчується на MVC, хоча все інше досить доладно описано. Про MVP та її послідовників можна поситати на сайті Мартіна Фолера. Наприклад тут. Референс реалзації можно дивитися буть де. Для мене найбільш привабливі, це ті які йдуть разом з усілякими факторіями від Майкрософту. Наприклад Service Factopry та Web Client Factory. Привабливі томущо розроблені на .Net та за допомогою Object Builder. Швидше за все такі самі є і від інших вендорів.

---

MCPD(Web,Windows,Enterprise), MCTS (WPF, WCF)

Просто ссылка по теме. Описывает отличия MVP от MVC.

http://rsdn.ru/article/patterns/ModelViewPresenter.xml