Железобетонный MVC

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Хочу поделиться одним выводом, который я сделал, разбираясь с «новым» фреймворком ASP.NET MVC.

Декларируемые отличия от WebForms выглядят примерно так:

— Слабосвязанная архитектура;
— Отсутствие хранения состояний представления, т.е чистый REST(?);
— Полный контроль над разметкой;
— Покрытие тестами всех компонентов;

Всё это замечательно, но мало где упоминается о том, что все слои архитектуры качественного приложения должны быть нанизаны и приварены к стальной арматуре и залиты бетоном. И любое изменение в требованиях ведёт к изменению всех слабосвязанных слоёв начиная от таблицы в БД и заканчивая тестами.

Я не говорю что это плохо. Просто это надо учитывать при проектировании.

У полноценного MVC приложения обычно есть примерно следущий набор слоёв хранения и управления данными
— Таблицы в БД
— Сохранённые процедуры и представления в БД
— ORM
— DLL (Repository, Mock etc)
— BLL
— Controllers
— Views

плюс Тесты.

Разумеется, все эти слои достаточно независимы, но необходимо учитывать, что они независимы только в рамках строжайшего отображения предметной области. Любое изменение понимания предметной области приведёт к одновременному изменению всех этих слабосвязанных слоёв. Кажущаяся независимость на самом деле является максимальной строгостью и не допускает вольностей которые позволяет управление состоянием в WebForms.

Можно привести аналогию с тетрадью* со сменными блоками. Вы можете доставать или вставлять листы, можете рассыпать их по комнате и собрать обратно, но только те листы в которых перфорация точно соответствует расположению дуг кольцевого замка и их размерам. Иначе вам придётся дырявить новый лист.

Безусловно, вы можете делать что угодно в каком-угодно слое и это даже будет работать. Можно точно также как в в любой программе смешать UI и бизнес-логику в разных частях приложения, написать максимальное количество хелперов и частичных представлений, но зачем тогда использовать MVC?

*Тетра́дь (от греч. τετράδιον — четвертая часть листа, от греч. τέτρα — «четыре») — носитель информации, предмет для произведения записей, состоящий из скреплённых листов белой бумаги. ru.wikipedia.org/wiki/Тетрадь

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

У полноценного MVC приложения обычно есть примерно следущий набор слоёв хранения и управления данными

ASP.NET MVC это фреймворк для создания веб-интерфейса и ничего более. У него нет никаких «слоев», особенно ORM и таблиц в базе. И он не накладывает никаких жестких требований на архитектуру приложения.

Кажущаяся независимость на самом деле является максимальной строгостью и не допускает вольностей которые позволяет управление состоянием в WebForms.

Не в обиду Вам будет сказано, но такое впечатление что после WebForms — формошлепского проекта (без нормальной доменной модели) девелопер увидел пример «правильного» MVC приложения.

Строгая доменная модель она и создается для того, что бы отражать предметную область и тем самым уменьшать количество багов. А сам MVC можно использовать для формошлепства еще проще, чем Web Forms.

Ты передёргиваешь.
я сказал

у полноценного MVC приложения

ты запрягаешь

ASP.NET MVC это фреймворк

это очевидно разные сущности.

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

По русски говорю ещё раз — оба фреймворка базируются на ASP.NET, оба с одинаковой степеью используют слабосвязанную архитектуру, но прорывной MVC неожиданно требует привязки класса для вида в котором вынужденно смешиваются и UI и бизнеслогика. Причём класс этот заведомо избыточный если говорить о модели.

Насчёт формошлёпства как такового я думаю всё-таки некоторые мои нашлёпаные формы пока просто не реально реализовать в MVC в разумные сроки и за примлемый бюджет. И в результате получится страница (вид) намертво связанный с предметной областью и ни о каком «полном управлении разметкой» речи идти не может, если конечно подразумевалась разумная, полезная разметка а не сферическая. Внесение же изменений будет по стратегии «до основанья а затем».

Недаром так стремительно набирают обороты шаблоны, кодогенерация и яваскриптовые фреймворки для MVC.

По русски говорю ещё раз — оба фреймворка базируются на ASP.NET, оба с одинаковой степеью используют слабосвязанную архитектуру, но прорывной MVC неожиданно требует привязки класса для вида в котором вынужденно смешиваются и UI и бизнеслогика.
Что же это такое он требует? Ты имеешь ввиду модель? Так она не обязательна. Через ViewDataDictionary можно прокидывать любые нетипизированные данные.
А в разметке MVC намного гибче — можно писать вообще что угодно, без привязки к формам и контролам как в веб-формах.
Как-то непонятно в чем задача: переписать готовое приложение с веб-форм на MVC? Или использовать MVC в новом приложении для быстрого формошлепства как на веб-формах?

Требует модель на модель. Которая де факто связывает UI и BL покруче чем формы.

Нет никакой задачи. Просто хотел поделится наблюдением — разработка под MVC требует тщательности даже по сравнению с WebForms которое написано по всем канонам бест-практик.

У меня какие-то притензии получаются — на самом деле мне всё нравится в MVC.

Все верно, у правильно спроектированного приложения на вебформах (обычно MVP, но при желании можно реалзиовать и MVC паттерн) есть все те же самые слои, тесты и т.д.
а слабосвзянность архитектуры зависит не от фреймворка, а от разработчика. Использовать многоуровневую архитектуру, интерфейсы, DI контейнеры и т.д. нужны и в приложениях на веб-формах, и на винформах или wpf. Мне кажется что антипатерн «Magic button» прочно засел в головах людей, пришедших в мир веб-программирования с вебформ :-)

А отвечая на вопрос — MVC фреймворк нужно использовать для того, чтобы не изобретать свой движок и не использовать тяжелый и тормознутый движок WebForms.

Я думаю, что возможная и желаемая сложность интерфейса WebForms затрудняет создание идеальной архитектуры. То есть одностраничный UI может быть настолько сложным и запутаным насколько это поместится в голове заказчика или разработчика. Так сложилось исторически.

В MVC же создание сложного одностраничного UI сразу приводит к пониманию значительно увеличенной сложности M С которая никак не может быть понижена. В WebFrms понижение сложности, с одновременным ростом запутанности, происходит благодаря «антипатерну».

MVC имеет неоспоримое маркетинговое преимущество — лёгкие страницы, что является важным в эпоху мобильного бума. Но разработка на MVC несколько сложнее, причём не только в плане ручной разметки и вспоминания основ HTML. Собственно это я и хотел сказать.

Опять озаряет? cirw.in/...time-to-move-on обсуждали на хакернеьюс совсем недавно

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

Просто поделился наблюдением, которого в явном виде в учебниках нет — MVC подход нуждается в более глубокой проработке модели в контексте планируемого UI приложения

Прочитал. Тебе твой английский тоже пока не даёт возможности улавливать идею. Или твой русский. Или мой русский )

Там немного о другом. Там говорится о проблеме роста контроллеров. И чувак пытается добавить ещё один слой Операторов(?) для решения этой проблемы.

Я же говорю о том что изменения скорее всего должны затрагивать все слои и это необходимо учитывать при проектирование. Пытаться запихнуть все возмущения системы в контроллер это путь к псевдоспагетти, который есть в WebForms. Только там для этого используют файл кода страницы.

добро пожаловать в увлекательный мир програмирования.

Любое изменение понимания предметной области приведёт к одновременному изменению всех этих слабосвязанных слоёв.

Это нормально.

Это зависит от степени необходимой детерминированности модели. В MVC она выше.

Всё это замечательно, но мало где упоминается о том, что все слои архитектуры качественного приложения должны быть нанизаны и приварены к стальной арматуре и залиты бетоном. И любое изменение в требованиях ведёт к изменению всех слабосвязанных слоёв начиная от таблицы в БД и заканчивая тестами.

Можно привести аналогию с тетрадью* со сменными блоками. Вы можете доставать или вставлять листы, можете рассыпать их по комнате и собрать обратно, но только те листы в которых перфорация точно соответствует расположению дуг кольцевого замка и их размерам. Иначе вам придётся дырявить новый лист.

Может художественная ценность у этого текста большая, но информации в нем мало.

Можно какие-то конкретные примеры?

В целом оба варианта, на моё имхо, могут быть реализовны почти идентично.

Но вот например для отображения связанных таблиц на одной странице в MVC принято делать отдельный класс типа
public class Conglamerat
{
IEnumereable<city> Cities {get; set;}
IEnumereable<street> Streets {get; set;}

}

А WebForms позволяет использовать родные классы City и Street на одной странице самостоятельно но для достижения того же результата — отображение улиц по городам, в частности.

То есть эта буква M — подразумевает что мы передаём для отображения не просто model а модель изменённую соответствующим образом.

В WebForms можно дотащить всё что угодно и собрать необходимый венигрет уже на месте. Тот же пример когда параметр для метода берётся из соседнего GridView который вообще ничего не знает о тех моделях которые есть на нашей странице.

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

То-есть, с WedForms на странице у тебя есть доступ ко всем методам и ты можешь запрашивать любые объекты с любыми данными. А в случае с MVC, можно работать только с теми данными которые ты заранее передал на страницу через модель. То есть только с теми объектами и теми данными которые ты заранее позаботился положить модель? И тебе не нравится что если нужны дополнительные данные — нужно править этот «лишний» класс? Я правильно понял?

Но так ведь, и страница в ASP.NET MVC, это не совсем страница как раньше, а просто отображение + клиентская сторона (скрипты), а тот серверный код что раньше был в страницах должен был быть, теперь находится в контролерах, а там у тебя есть доступ ко всем классам и методам на прямую без промежуточной модели как и раньше.
То есть я согласен — что эту «лишнюю» промежуточную модель нужно переписывать в случае если нужны другие данные на виве, но это всего лишь изменения в одном классе лишнем, а изменения в контроллере/виве — будут как в MVC, так и в классическом варианте в одинаковой мере мне кажется.

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

Выбор между WinForms и MVC очень прост:

Если нужен TDD или полный контроль над HTML — однозначно MVC.

Если нужен RAD или веб-морда для БД — однозначно WebForms.

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

Да, реагируют почти одинаково. Но в WebForms меньше ответственности, меньше необходимостей для внесения изменений — всё равно тесты только на половину, да и то.

Вот как раз я хотел сказать наоборот — в MVC когда смотришь на UI вынужден смотреть через все слои на данные и бизнес-логику. В WebForms — просто словно кто-то сидит на левом плече и подначивает начать делать спагетти и уверяет, что прокатит и будет быстрее и будет работать.

Нет слабосвязанных слоёв — нет смысла в MVC. А если есть то тогда изменение в моделировании приводят к изменению во всех слоях. Как-то так.

По большому счёту, разумеется, что разница между MVC и WebForms не так уж велика и никто не мешает начать делать вызовы через ADO.Net и другие глуппости.

Коментар порушує правила спільноти і видалений модераторами.

Если нужен RAD или веб-морда для БД — однозначно WinForms.

WinForms? Может WebForms? (хотя я тоже пару раз путал случайно в разговорах)

Однозначно?

Ну разве что, если под RAD подразумевается — создание кошмарных-низкокачественных приложений в короткие сроки. Тогда однозначно WebForms.

Но я бы все таки предпочел какой то другой RAD.
Вот Windows Froms — это действительно хороший RAD, и UI библиотека.
А вот WebForms, лучше бы поскорее закопали, и поглубже.
А ASP .NET MVC я бы выбрал бы только за чистый html, за Razor, за REST, и за маппинг HTTP параметров в объекты, и за то что ни у кого из работающих над проектом не будет возникать мысль запихнуть туда тонну контроллов с вистейтами, с разметкой в 2мб на страницу, и сделать визард в котором можно пройтись по 20ти ентитям из базы, при том что в URL так и будет висеть ID первого, и в добавок фейковый AJAX поверх всего, который и преимуществ не дает, и при этом создает большую неразбериху с вивстейтами. Даже если бы TDD и MVC подходы не нужен был бы, и не использовались бы.

Мое скромное мнение.

WinForms? Может WebForms? (хотя я тоже пару раз путал случайно в разговорах)
Ага, опечатка.

Ну вот к примеру, у вас приложение, целиком состоящее из морд таблиц. WebFormовскими датагридами и и листвью такое можно засобачить раз в 5 быстрее, чем в MVC. Что касается всего остального, никто вам не мешает отказаться от вьюстейта и делать свои компоненты, с минимальным ХТМЛ. Хотя тогда уже о RADе речи нет...

Коментар порушує правила спільноти і видалений модераторами.

Я лично не использую MVC ради TDD, подумаешь контроллеры можно покрыть тестами, то еще преимущество... Вот список бенефитов этого фреймвока перед формами:
1) Razor
2) Типизированные представления (в формах типизированные контролы появятся только в .Net 4.5)
3) Экшены. Имхо намного удобнее обработчиков событий. С аяксом тоже работать намного проще.
3) Контроль над разметкой, преимущества в работе с клиентским кодом.
4) Возможность иметь несколько форм на странице.
5) Встроенная урл маршрутизация.
6) Model Binding вместо Viewstates
7) Более прозрачный (менее извращенный) цикл обрабоки запросов
... блин уже 3 раз дописываю

8) Прозрачное разделение запросов на типы. Никаких IsPostback поверок и прочей ереси

Почти согласен. Правда аргументы про формы и маршрутизацию мне кажется сомнительными: несколько форм на странице — не такая уж необходимая фича, а маршрутизацию и ВебФормах можно прикрутить за пять минут.

Підписатись на коментарі