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

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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

Рядом

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

уже упомянутый @bakoyaro и @arjan

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

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

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

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

Ответ 3

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

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

Разделив проблемы на 3 отдельные части, вы также облегчите истинное модульное тестирование. Уровень презентации может быть протестирован без модели или контроллера и наоборот.

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

Ответ 4

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

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