Почему MVC так популярен?
архитектурный шаблон MVC имеет 3 зависимости. Вид зависит от модели. Контроллер зависит от вида и модели. Модель является независимой.
архитектурный шаблон слоев определяет N-1 зависимостей, где N-количество Слои.
учитывая три слоя: модель, представление и контроллер, существует только 2 зависимости, в отличие от 3 с традиционным MVC. Структура выглядит так:
View ---> Controller ---> Model
[вид зависит от контроллера, контроллер зависит от модели]
Мне кажется, что этот стиль достигает той же цели и производит более слабое соединение. Почему этот стиль не более распространен? Правда добиться того же цели?
Edit: нет ASP.NET MVC, просто шаблон.
что касается поста григса:
- что касается насмешки, Layers по-прежнему позволяет использовать шаблон командного процессора для имитации щелчков кнопок, а также любого другого диапазона событий.
- UI изменения по-прежнему очень легко, возможно, даже проще. В MVC контроллер и представление имеют тенденцию объединяться. Слои создают строгое разделение. Оба слоя черные ящики, свободно варьироваться независимо в реализации.
- контроллер имеет 0 зависимостей от представления. Представление можно записать, и время все еще можно сохранить с свободным соединением.
8 ответов
потому что вы отделяете интерфейс от контроллера, делая изменения проще.
также рассмотрите сценарий, в котором вам нужно начать работу над проектом, но произведение не будет готово в течение нескольких недель или месяцев. Вы ждете или пишете весь код, необходимый для страниц, а затем просто подключаете представление к контроллеру.
по крайней мере, это то, что мы сделали и мы спасли месяцев.
также это сделало изменения пользовательского интерфейса легче справиться, потому что не было никаких код на наших страницах aspx, который что-то сделал.
наши тесты также были лучше, так как мы могли макетировать все, включая нажатия кнопок и т. д.
и если вы говорите о asp.net-MVC framework, нет кода в файлах aspx и нет viewstate и т. д.
в правильном MVC контроллер не зависит от вида afaik. Или, может быть, я неправильно его понимаю.
модель определяет данные.
представление определяет, как выглядит вывод.
и контроллер является переводчиком из модели-понятной грамматики для просмотра-понятной грамматики.
таким образом, по существу, контроллер является независимым. Точка зрения независима. И модель независима.
да? Нет?
Я буду смелым, и постарайтесь объяснить, почему ваш метод не прижился.
шаблон MVC в основном требует, чтобы слои представления и модели согласовали API. Поскольку один служит другому, и внутри кода нет зависимостей, он оставляет контроллер вести себя обобщенно, все, что ему нужно сделать, это взять определенную структуру в слое представления и вызвать соответствующий API на слое модели.
вы заметите, что согласование API между представлением и моделью на самом деле не в любом случае, это должно произойти. И то, что вы получаете,-это хорошее разделение между back-end front-end development.
в вашем предлагаемом решении требуется много разработки со стороны контроллера. Контроллер должен понимать все элементы в представлении и сопоставлять их с конкретными вызовами, требуемыми для слоя модели. Поскольку контроллер является одной точкой доступа, соединяющей многие виды со многими моделями, это может быстро выйти из-под контроля и в конечном итоге непонятный модуль контроллера.
посмотрите на некоторые примеры Struts2, чтобы понять, что я имею в виду...
Я думаю, что понимаю вашу точку зрения:
Да, вы можете сделать представление зависящим только от контроллера, только сделав преобразование контроллера (используя PHP в качестве примера) объектами модели для объектов не-модели, таких как простые массивы.
Как мы уже знаем, выполнение этого преобразования может быть больше усилий, чем стоит, если развязка на самом деле не нужна. Если представление использует объекты модели, то оно имеет эту зависимость. Тем не менее, это может быть немного облегчено наличие представления зависит исключительно от контроллера для его требуемого ввода, который может быть объектом модели.
платформа Symfony PHP способствует этому стилю перетасовки тощего контроллера между моделью и представлением. Вы все еще можете напрямую вызвать слой модели для извлечения объектов в слое представления, но это настоятельно рекомендуется для проблем связи, которые вы поднимаете. В представлении вы можете вызвать include_component (), который фактически возвращается к контроллеру, если вам нужно запросить Модель.
Я не возвращался к этому долгое время, в основном потому, что я все еще думал. Я был недоволен полученными ответами, они на самом деле не ответили на мой вопрос.
профессор, недавно, направил меня в правильном направлении. По сути, он сказал мне следующее: слои, которые разделяют Модель, Вид и контроллер is MVC. В архитектурном шаблоне vanilla MVC зависимость между представлением модели часто не используется, и вы фактически заканчиваете Слои. Идея та же самая, название просто плохое.
Выбор шаблона презентации для новой или корпоративной веб-разработки на платформе Microsoft является сложной задачей, на мой взгляд, есть только три; модель представления, модель-представление-ведущий (MVP) или ASP.NET MVC (производная Model2).
вы можете прочитать полную статью здесь ASP.NET Шаблоны MVC
Я хотел бы добавить еще несколько вещей. Прежде всего, с моей точки зрения, мы используем модель как контейнер для информации, которую мы хотим передать и показать в представлении. Обычно метод действия в контроллере заканчивается представлением возврата ("viewName", model).Сам вид, вероятно, изменит свой layour против модели:
вид :
if (модель.что-то==true) {
%>
что-то показать
}
At этот poinf определение модели трудно найти.
Я могу сказать (особенно на enterprise conext), что это две "модели"
один-это модель домена / модель сущности или как вы хотите ее назвать, которая обертывает данные, поступающие из нижних слоев (база данных и т. д.), и модель представления, которая содержит информацию, которую мы хотим показать, плюс любую другую информацию, которую нам нужно Скрыть/показать часть интерфейса
контроллер оркеструет представления и является независимым от зрения, но немного dipendent от модели:
в контроллер
Pulic actionResult Index () {
....
if (модель.BoolProperty= = true) {
return ("firstView);
}
else
{
return ("secondView");
}
}
надеюсь, это имеет смысл
на мой взгляд, вам лучше попробовать это в своей программе, вы можете использовать ruby on rails или codeigniter( для php ),эти отличные рамки могут быть полезны для вашего понимания MVC.