Каковы основные преимущества шаблона MVC по сравнению со старомодным 3-слойным шаблоном?

Question

Я размышляю об использовании шаблона MVC в моем новом проекте, и я ясно вижу главное преимущество в том, что я могу поместить слой данных (модель) немного ближе к уровню представления (представлению), что позволитнебольшое увеличение скорости приложения.Но кроме точки зрения производительности, есть ли другие преимущества MVC по сравнению с многоуровневым шаблоном типа view-logic-data?

EDIT: Для тех, кто заинтересован, я только что загрузил пример PHP-кода, которыйЯ создал, чтобы проверить использование MVC.Я специально пропустил все проверки безопасности, чтобы сделать код немного легче для чтения.Пожалуйста, не критикуйте это слишком сильно, потому что я знаю, что это могло бы быть намного более усовершенствованным и продвинутым, но тем не менее - это работает !!!Буду рад вопросам и предложениям: вот ссылка: http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip

Answer 1

Разделение интересов, которое считается преимуществом MVC, на самом деле является также продвижением 3-уровневой / 3-уровневой системы. Там также бизнес-логика независима и может использоваться на разных уровнях представления.

Основным отличием является то, что в классическом MVC модель может иметь ссылку на вид. Это означает, что при обновлении данных модель может отправить эти данные обратно, возможно, к нескольким представлениям. Ярким примером является настольное приложение, в котором данные визуализируются несколькими способами. Это может быть так же просто, как таблица и график. Изменение в таблице (которое является изменением в одном представлении) сначала проталкивается через контроллер в модель, которая затем выталкивает его обратно в график (другое представление). Затем график обновляется.

Поскольку разработка настольных систем находится в состоянии упадка, многие программисты связываются с MVC только в некоторых веб-вариантах, например через JSF в Java EE.

В этих случаях модель почти никогда не имеет ссылки на вид. Это связано с тем, что сеть в основном основана на запросах и ответах, и после того, как запрос был обработан, сервер не может отправлять дополнительную информацию. То есть обновление, передаваемое от модели к клиенту, будет бессмысленным. С обратным ajax / comet это меняется, но многие сетевые MVC-фреймворки все еще не используют это в полной мере.

Таким образом, в случае веб-ориентированного MVC типичный «треугольник» между M, V и C меньше, и этот вариант MVC фактически ближе к n-уровневой модели, чем «истинный» MVC.

Также обратите внимание, что некоторые веб-фреймворки MVC имеют промежуточную соединительную часть между M, V и C, называемую компонентом поддержки (Java / JSF) или кодом позади (ASP.NET). В JSF контроллер предоставляется платформой, и представление часто не привязывается напрямую к модели, а использует этот компонент поддержки в качестве посредника. Базовый компонент очень тонкий и в основном просто предварительно извлекает данные из модели одним способом и преобразует конкретные сообщения модели (например, исключения) в конкретные сообщения просмотра (например, некоторый читаемый человеком текст).

Answer 2

Рядом

• повторное использование кода,
• разделение проблем,
• меньше связей между слоями,

уже упоминалось@bakoyaro и @ arjan

Я думаю, что MVC лучше, чем 3-уровневый, в сочетании с шаблоном «соглашение о конфигурации» .(т.е. "ruby on rails" или Microsoft "MVC for asp.net").

По моему мнению, эта комбинация приводит к улучшению и упрощению обслуживания кода .

Во-первых, это усложняет изучение mvc-framework, так как вам нужно изучить соглашения (а-ля контроллеры идут в папку контроллеров и должны называться xxxxxcontroller)

Но после того, как вы узнали соглашения,легче поддерживать свой и чужой код.

Answer 3

Забудьте об увеличении скорости приложения, перейдя в MVC.Самым большим преимуществом я обнаружил простоту повторного использования кода.После того, как вы перейдете в MVC, не будет никаких зависимостей от представления ваших данных или хранения фактических данных.

Например, вы можете написать сервлет, который обслуживал страницы .jsp в качестве уровня презентации, а на следующий день написать веб-сервис в качестве еще одного уровня представления для существующих моделей и контроллеров.Как мудрый, если вы хотите или должны переключить вашу СУБД.Поскольку доступ к модели полностью отделен от всего остального, вам просто нужно переписать только ваши объекты доступа к данным, чтобы вернуть данные так, как ваш контроллер может их обработать.

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

С другой стороны, я часто чувствовал, что аббревиатура MVC была неточной.Всякий раз, когда я вижу это, я думаю об этом как Вид-> Контроллер-> Модель .Уровень представления никогда не будет содержать код DAO, и в модели никогда не будет логики представления.Контроллер вынужден действовать как посредник.

Answer 4

В тех случаях, когда 3-уровневая схема отделяет представление от доступа к бизнесу и данным, MVC - это шаблон уровня представления, который дополнительно отделяет модель (данные) от представления (экран) и контроллера (ввод).

Нельзя выбирать MVC более чем 3-х уровневый / 3-х слойный. Используйте их обоих.