MVC против n-уровневой архитектуры [закрыто]
5 ответов
Архитектура N-tier обычно имеет каждый слой, разделенный сетью. Т.Е. уровень представления находится на некоторых веб-серверах, затем это говорит с серверами приложений бэкенда по сети для бизнес-логики, затем это говорит с сервером базы данных, снова по сети, и возможно сервер приложений также обращается к некоторым удаленным сервисам (скажите что Authorize.net для обработки платежей).
MVC является шаблоном разработки программирования, где различные части кода ответственны за представление Модели, Представления и контроллера в некотором приложении. Эти две вещи связаны, потому что, например, уровень Model может иметь внутреннюю реализацию, которая называет базу данных для того, чтобы сохранить и получить данные. Контроллер может находиться на веб-сервере и удаленно назвать appservers для получения данных. Краткие обзоры MVC далеко детали того, как архитектура приложения реализована.
N-tier просто относится к физической структуре реализации. Эти два иногда путаются, потому что дизайн MVC часто реализуется с помощью архитектуры N-tier.
Джерри: Вот простой пример того, как они связаны:
Уровень 1 - состоит из моделей, которые взаимодействуют с уровнем 2 через какой-то сетевых служб или аналогичных, контроллеры для проверки ввода, вычислений и других вещей, относящихся к представлениям. И, конечно же, он содержит сами представления, которые могут быть графическим интерфейсом в настольном приложении или веб-интерфейсом в веб-приложении.
Уровень 2 - Содержит какой-либо вид службы или другой способ получения сообщения уровня 1. Не знает / не должен знать об уровне 1, поэтому могу отвечать только на звонки сверху - никогда не просите ничего в одиночку. Также содержит всю бизнес-логику.
Уровень 3 - Содержит модель предметной области, объектное представление базы данных и всю логику для связи и обновления записей базы данных.
Это то, что 
говорят о n-уровневой архитектуре
На первый взгляд, три яруса могут кажутся похожими на MVC (Model View) Концепция контроллера), однако, топологически они разные. A основополагающее правило в трёхуровневой системе архитектура никогда не является уровнем клиента взаимодействует напрямую с данными ярус; в трехуровневой модели все коммуникация должна проходить через промежуточный уровень. Концептуально трехуровневая архитектура линейная. Однако, архитектура MVC треугольный: Вид посылает обновления контроллер, контроллер обновляет Модель, и Вид обновляется прямо из модели.
Основное правило трехуровневой архитектуры - клиентский уровень никогда не взаимодействует напрямую с уровнем данных; в трехуровневой модели все коммуникации должны проходить через промежуточный уровень.
Это лайнерная архитектура. Это решает вопрос о том, как передавать информацию между пользователем и базой данных. Где, поскольку MVC является треугольной архитектурой: представление отправляет обновления в контроллер, контроллер обновляет модель, а представление обновляется непосредственно из модели. Это отвечает на вопросы о том, как пользовательский интерфейс управляет компонентами на экране.
Если бы 3-уровневый дизайн был таким:
Client <-> Middle <-> Data
шаблон MVC был бы таким:
Middle
^ |
| v
Client <- Data
Это означает, что:
- в 3-уровневом эквиваленте связь между уровнями двунаправленная и всегда проходит через средний уровень
- в MVC-эквиваленте связь однонаправленная; можно сказать, что каждый "слой" обновляется тем, который находится слева, и, в свою очередь, обновляет тот, который находится справа - где "слева" и "справа" просто иллюстрация
P. S. Client будет View, а Middle - Controller