Comments 24
как можно упростить жизнь на таких проектах используя все тот же шаблон Model-View-Controller
вы только усложните жизнь тем, кто будет поддерживать подобный проект. не нужно искать себе преключений на ровном месте.
если вы только начинаете работать над проектом и вам пришла в голову мысль сдалть Webforms, но с MVC — нет никаких причин этим заниматься — берите ASP.NET MVC и вперед.
если же вы собралиь переписать какой-нибудь старый проект — то тем более не стоит этого делать, скорее всего получите спагеттиобразный код.
я, к сожалению, сталкивался в своей практике с подобными решениями — это было ужасно.
+2
Есть еще третий случай — когда есть старый проект с сотнями вебформ, написанный многими поколениями разработчиков. Его довольно бессмысленно уже переписывать на MVC, но новую функциональность добавлять приходится постоянно. И тут подходы в духе описанного очень помогают хотя бы часть проекта написать более-менее нормально и худо-бедно покрыть тестами.
Идея не нова, у gaidar и XaocCPS в их книжке по MVC что-то подобное, например, описано.
Идея не нова, у gaidar и XaocCPS в их книжке по MVC что-то подобное, например, описано.
0
именно для этих целей шаблон и применяется, как в первом абзаце и написано.
0
я вам больше скажу — об этом подходе то ли Гаттри, то ли Хансельманн писал.
если вы часть проекта напишите в одном стиле, а часть в другом — то получите зоопарк, с которым еще намучаетесь на поддержке. «в армии все должно быть безобразно, но единообразно» — не нужно стараться сделать хоть что-то «более менее нормально», обычно это только усугубляет ситуацию.
если вы часть проекта напишите в одном стиле, а часть в другом — то получите зоопарк, с которым еще намучаетесь на поддержке. «в армии все должно быть безобразно, но единообразно» — не нужно стараться сделать хоть что-то «более менее нормально», обычно это только усугубляет ситуацию.
-1
Правильно ли я понимаю - Вы считаете что лучше переписать все,
чем позволить временно существовать двум шаблонам?
К сожалению чаще всего получить одобрение бизнеса на такое масштабное изменение
достаточно проблематично.
Да и достаточно рискованно. Потому как скорее всего попросят дать оценку,
а оценить такое масштабное изменение во первых сложно,
во вторых цифра получится большая и ее придется отстаивать,
а в третьих велика вероятность ошибки и за нее придется отвечать.
Я понимаю что есть лучшие практики, и хорошо представляю себе что такое рефакторинг.
В больших системах иногда приходится мириться с временным существованием двух решений.
Как ни прискорбно это сознавать.
И конечно-же от таких временных ситуаций надо избавляться как можно быстрее.
чем позволить временно существовать двум шаблонам?
К сожалению чаще всего получить одобрение бизнеса на такое масштабное изменение
достаточно проблематично.
Да и достаточно рискованно. Потому как скорее всего попросят дать оценку,
а оценить такое масштабное изменение во первых сложно,
во вторых цифра получится большая и ее придется отстаивать,
а в третьих велика вероятность ошибки и за нее придется отвечать.
Я понимаю что есть лучшие практики, и хорошо представляю себе что такое рефакторинг.
В больших системах иногда приходится мириться с временным существованием двух решений.
Как ни прискорбно это сознавать.
И конечно-же от таких временных ситуаций надо избавляться как можно быстрее.
-1
я за единообразие в проекте. и за чистый код.
-1
В этом мы с Вами сходимся.
А на мой вопрос Вы к сожалению не ответили.
А на мой вопрос Вы к сожалению не ответили.
-1
Вы считаете что лучше переписать все,
чем позволить временно существовать двум шаблонам?
Насколько временно? все от проекта зависит, но в большинстве случаев я бы рекомендовал либо переписать все на ASP.NET MVC, либо вообще не прибегать к шаблону MVC.
Поделитесь опытом такого «временного» существования двух шаблонов — как долго это было и к каким результатам привело.
-1
на счет переписать все я высказал свои аргументы выше. есть еще варианты?
опыт есть - двойное решение существует уже два года. переписываем по мере необходимости.
как Вы знаете WebForms — инструмент достаточно гибкий и позволяет написать одно и тоже многими способами. после внедрения этого шаблона программисты стали писать код единообразно. он прост и доступен даже новичку, ему легко следовать, код легче проверять.
на большом количестве проектов в течении, наверное, лет 15 возникало желание отделить логику страницы от событий и биндингов. применялись различные подходы, но все они, в итоге, сводятся к подобным решениям.
Вы сказали что можно вынести логику страницы не используя MVC.
Приведите пожалуйста пример.
опыт есть - двойное решение существует уже два года. переписываем по мере необходимости.
как Вы знаете WebForms — инструмент достаточно гибкий и позволяет написать одно и тоже многими способами. после внедрения этого шаблона программисты стали писать код единообразно. он прост и доступен даже новичку, ему легко следовать, код легче проверять.
на большом количестве проектов в течении, наверное, лет 15 возникало желание отделить логику страницы от событий и биндингов. применялись различные подходы, но все они, в итоге, сводятся к подобным решениям.
Вы сказали что можно вынести логику страницы не используя MVC.
Приведите пожалуйста пример.
-1
то есть без MVC вы логику вне codebehind класса представить не можете? Очень странно. вы разбиваете свои приложения на слои? Business Logic Layer, Data Access Layer etc. — например?
-1
почему же, я могу себе даже представить довольно сложную страницу которая объединяет в себе несколько бизнес сущностей и эта логика специфична для страницы. т.е. не должна быть в доменной области приложения.
и я бы хотел эту логику вынести из code-behind и структурировать ее так чтобы можно было части этой страницы использовать повторно.
предложите Ваше решение пожалуйста.
и я бы хотел эту логику вынести из code-behind и структурировать ее так чтобы можно было части этой страницы использовать повторно.
предложите Ваше решение пожалуйста.
-1
в доменном слое вообще никакой логики не должно быть.
если вам нужны какие-либо части этой страницы как контролы — User или Custom Controls — ваш выбор. если остальную логику можно вынести в бизнес слой. часть логики, часто в таких случаях остается в code behind классе, но минимальная часть — именно спецефичная для вашей страницы. если вы ее где-то еще хотите использовать, то можно сделать базовую страницу и наследоваться от нее.
если вам нужны какие-либо части этой страницы как контролы — User или Custom Controls — ваш выбор. если остальную логику можно вынести в бизнес слой. часть логики, часто в таких случаях остается в code behind классе, но минимальная часть — именно спецефичная для вашей страницы. если вы ее где-то еще хотите использовать, то можно сделать базовую страницу и наследоваться от нее.
-1
Вы на вопрос мой не ответили. Прочитайте пожалуйста внимательно.
-1
не вижу ни одного вопроса, на который бы я не ответил. повторите, пожалуйста, если не трудно — какой именно.
на мой взгляд, применение шаблона MVP (вижу, вы все-таки отредактировали это в статье) для Webforms приложений в большинстве случаев неоправданно, вы считаете иначе — думаю, друг друга мы тут не переубедим.
на мой взгляд, применение шаблона MVP (вижу, вы все-таки отредактировали это в статье) для Webforms приложений в большинстве случаев неоправданно, вы считаете иначе — думаю, друг друга мы тут не переубедим.
-1
и я бы хотел эту логику вынести из code-behind и структурировать ее так чтобы можно было части этой страницы использовать повторно.я хочу отделить логику страницы от событий и биндинга данных.
предложите Ваше решение пожалуйста.
хочу видеть в codebehind только DataBind и обработку событий.
логику страницы хочу видеть отдельно.
под логикой страницы я понимаю:
— загрузку словарей
— подготовку данных для вывода пользователю
— хранение используемых моделей
— вызовы методов бизнес логики
— логика настройки отображения
например: если эта модель заполнена, то подгрузить зависимую
— взаимодействие между составными частями страницы
например: заполнен фильтр -> нажата кнопка поиска -> передаем данные в блок получения результата
Для меня это насущная проблема, как и для Eltaron и elw00d
Если не использовать подобный описанному подход, то как?
Если Вы не видите в этом разделении смысла, можно не отвечать.
-1
То есть вы предлагаете новый функционал писать в старом стиле чуть ли не с бизнес-логикой прямо в обработчиках событий в .aspx.cs-файле? Не, не согласен я. Пусть лучше будет зоопарк — благо он обычно в старых больших проектах и так уже какой-нибудь, да есть :)
0
На MVC это не очень похоже, скорее MVP.
+1
Если сравнить MVC и MVP - разница между ними только в хранении состояния. MVP частный случай MVC согласно их описанию. Сравнить можно например вот здесь и здесь.
По этому я предпочел такое название. Вы можете сами выбрать MVC или MVP.
При этом представленный код будет работать в обоих случаях.
Для реализации MVP возможно придется добавить сохранение состояния между постбэками.
По этому я предпочел такое название. Вы можете сами выбрать MVC или MVP.
При этом представленный код будет работать в обоих случаях.
Для реализации MVP возможно придется добавить сохранение состояния между постбэками.
-1
перечитал, был не прав. это классический MVP
0
Три с половиной года назад работал в компании, где писал на ASP .NET WebForms. И у нас был свой MVC-фреймворк, написанный нашим гуру тимлидом. На мой взгляд он был достаточно удобен для разработки в WebForms. Если вам интересно, я могу скинуть пару классов в личку, чтобы вы посмотрели, как это было реализовано у нас.
PS. Я бы предоставил вьюшке доступ к модели напрямую, потому что Presenter.Model.* писать каждый раз это не очень. А Presenter.Save() и другие методы презентера я бы инкапсулировал в некий Action, чтобы вьюшка не зависела от интерфейса презентера. Наоборот, вьюшка должна предоставлять интерфейс ISomeView, и презентер должен иметь ссылку на этот интерфейс. Потому что в противном случае менять реализацию представлений будет сложнее, чем просто реализовать интерфейс ISomeView заново (так как придется учитывать семантику вызовов презентера, и в общем случае вьюшки не будут взаимозаменяемыми).
PS. Я бы предоставил вьюшке доступ к модели напрямую, потому что Presenter.Model.* писать каждый раз это не очень. А Presenter.Save() и другие методы презентера я бы инкапсулировал в некий Action, чтобы вьюшка не зависела от интерфейса презентера. Наоборот, вьюшка должна предоставлять интерфейс ISomeView, и презентер должен иметь ссылку на этот интерфейс. Потому что в противном случае менять реализацию представлений будет сложнее, чем просто реализовать интерфейс ISomeView заново (так как придется учитывать семантику вызовов презентера, и в общем случае вьюшки не будут взаимозаменяемыми).
0
очень интересно, посмотрю с удовольствием.
что касаемо инверсии управления между вьюшкой и презентером — я пробовал строить такую схему, получается сложнее для понимания и поддержки.
надо сравнить затраты на изменение презентера и вьюшек под него заточенных с затратами на реализацию и поддержку независимых вьюшек. в моем случае дешевле было первое.
посмотрю Ваш пример, возможно я до чего-то не догадался.
возможно мы несколько по разному понимаем назначение презентера. в моей схеме он выполняет всю работу по подготовке данных для вьюшки, также как и обработку данных поступающих от вьюшки.
тут есть ошибка не верно выставлять модель напрямую, правильно будет использовать для этого свойства презентера.
основная задача этого подхода отделить события и биндинги от логики страницы — избежать мешанины из этого всего.
потому как часто хватает сложностей связанных с жизненным циклом страницы, а если туда примешивается стейт сохраненный в контролах и ViewState, то становится совсем тяжко.
что касаемо инверсии управления между вьюшкой и презентером — я пробовал строить такую схему, получается сложнее для понимания и поддержки.
надо сравнить затраты на изменение презентера и вьюшек под него заточенных с затратами на реализацию и поддержку независимых вьюшек. в моем случае дешевле было первое.
посмотрю Ваш пример, возможно я до чего-то не догадался.
возможно мы несколько по разному понимаем назначение презентера. в моей схеме он выполняет всю работу по подготовке данных для вьюшки, также как и обработку данных поступающих от вьюшки.
тут есть ошибка не верно выставлять модель напрямую, правильно будет использовать для этого свойства презентера.
основная задача этого подхода отделить события и биндинги от логики страницы — избежать мешанины из этого всего.
потому как часто хватает сложностей связанных с жизненным циклом страницы, а если туда примешивается стейт сохраненный в контролах и ViewState, то становится совсем тяжко.
0
UFO just landed and posted this here
Sign up to leave a comment.
Применение паттерна MVP в классическом ASP.NET