MVC против n-уровневой архитектуры
Мне было интересно, в чем именно заключается разница между MVC(который является архитектурным шаблоном) и n-уровневой архитектурой для приложения. Я искал это, но не мог найти простое объяснение. Может быть, я немного наивен в понятиях MVC, поэтому, если кто-то сможет объяснить разницу, это было бы здорово.
ура
13 ответов
N-уровневая архитектура обычно имеет каждый уровень, разделенный сетью. То есть уровень представления находится на некоторых веб-серверах, затем он обращается к внутренним серверам приложений по сети для бизнес-логики, затем он обращается к серверу базы данных, снова по сети, и, возможно, сервер приложений также вызывает некоторые удаленные службы (скажем Authorize.net для обработки платежей).
MVC - это шаблон проектирования программирования, в котором различные части кода отвечают за представление модели, представления и контроллера в некотором приложении. Эти две вещи связаны, потому что, например, уровень модели может иметь внутреннюю реализацию, которая вызывает базу данных для хранения и извлечения данных. Контроллер может находиться на веб-сервере и удаленно вызывать серверы приложений для извлечения данных. MVC абстрагируется от деталей реализации архитектуры приложения.
N-уровень относится только к физической структуре реализации. Эти два иногда путаются, потому что проект MVC часто реализуется с использованием N-уровневой архитектуры.
Если бы 3-уровневый дизайн был таким:
Client <-> Middle <-> Data
скороговоркой MVC будет:
Middle
^ |
| v
Client <- Data
Означающий, что:
- в трехуровневом эквиваленте связь между слоями является двунаправленной и всегда проходит через средний уровень
- в эквиваленте MVC связь является однонаправленной; мы могли бы сказать, что каждый "слой" обновляется тем, который слева, и, в свою очередь, обновляет тот, который справа - где "слева" и "справа" являются просто иллюстративными
PS Клиент будет View и Middle контроллера
Это то, что 
скажем про n-уровневую архитектуру
На первый взгляд, три уровня могут показаться похожими на концепцию MVC (Model View Controller); однако топологически они разные. Основное правило в трехуровневой архитектуре - уровень клиента никогда не связывается напрямую с уровнем данных; в трехуровневой модели все коммуникации должны проходить через промежуточный уровень. Концептуально трехуровневая архитектура является линейной. Однако архитектура MVC имеет треугольную форму: представление отправляет обновления контроллеру, контроллер обновляет модель, а представление обновляется непосредственно из модели.
Единственное сходство состоит в том, что эти две модели имеют три блока на своих диаграммах. Принципиально они совершенно разные по своему использованию. На самом деле, это не выбор между шаблоном, который нужно использовать, но оба шаблона могут быть вредно использованы вместе. Вот хорошее сравнение двух: http://allthingscs.blogspot.com/2011/03/mvc-vs-3-tier-pattern.html
Дай себе перерыв. И не ограничивайте себя определенными схемами при решении реальных проблем. Просто запомните некоторые общие принципы, одним из которых является ОТДЕЛЕНИЕ ЗАБОЛЕВАНИЙ.
Средство @Cherry Middle работает больше как обработчик запросов или перенаправитель в MVC Pattern.
Я хотел бы объяснить немного о MVC, по мне, Model View Controller работает следующим образом.
- Клиент инициирует сеанс, запрашивая любую услугу.
- Этот запрос принимается и обрабатывается контроллером (обработчик запросов, перенаправитель и т. Д.)
- Контроллер обрабатывает базовую информацию по запросу и перенаправляет ее в соответствующую модель, которая может заполнить запрос данных.
- Модель заполняет запрос в соответствии с параметрами, переданными контроллером, и отправляет результаты обратно в контроллер. (Примечание: здесь я хотел бы пояснить, что данные не возвращаются напрямую клиенту в истинной архитектуре MVC, а заполняются и возвращаются контроллеру.)
- Контроллер, чем отправить эти данные в View (клиент).
- Клиент имеет запрошенную услугу перед ним.
Это все о MVC, что я знаю.
Основное правило в трехуровневой архитектуре - уровень клиента никогда не связывается напрямую с уровнем данных; в трехуровневой модели все коммуникации должны проходить через промежуточный уровень.
Это линейная архитектура. Это решает вопрос о том, как передавать информацию между пользователем и базой данных. Где, поскольку MVC является треугольной архитектурой: представление отправляет обновления контроллеру, контроллер обновляет модель, а представление обновляется непосредственно из модели. Здесь рассматриваются вопросы о том, как пользовательский интерфейс управляет компонентами на экране.
N-уровневая архитектура лучше всего определяется с помощью диаграммы развертывания.
Архитектура MVC лучше всего определяется с использованием диаграммы последовательности.
2 не являются одинаковыми и не связаны, и вы можете объединить две архитектуры вместе. Многие компании предприняли шаги для создания архитектуры N Tier'd не только для развертывания и масштабируемости, но и для повторного использования кода.
Например, ваши объекты Business Entity могут потребляться настольным приложением, веб-службой, предоставляемой клиенту, веб-приложением или мобильным приложением. Простое использование подхода MVC не поможет вам вообще что-либо использовать.
Помимо линейности, еще одно существенное отличие, которое здесь недостаточно подчеркивалось, заключается в том, что в N-уровневой модели N не обязательно является 3-уровневым! Чаще всего он реализуется в виде трех уровней (представление, приложение, данные), а средний уровень имеет два подуровня (бизнес-логика и доступ к данным). Кроме того, модель в MVC может содержать как данные, так и бизнес-логику для манипулирования данными, тогда как в n-ярусах они будут отдельными уровнями.
Вывод: N-уровень - это архитектура, MVC - шаблон проектирования. Это один и тот же метафора, применяемый в двух разных областях.
Джерри: Вот простой пример того, как они связаны:
Уровень 1 - состоит из моделей, которые взаимодействуют с уровнем 2 через какую-либо сетевую службу или аналогичные контроллеры для обработки проверки входных данных, расчетов и других вещей, относящихся к представлениям. Кроме того, он содержит сами представления, которые могут быть графическим интерфейсом в настольном приложении или веб-интерфейсом в веб-приложении.
Уровень 2 - содержит какой-либо вид обслуживания или другой способ получения сообщений с уровня 1. Не знает / не должен знать о уровне 1, поэтому может отвечать только на вызовы сверху - никогда ничего не запрашивать сам по себе. Также содержит всю бизнес-логику.
Уровень 3 - содержит модель домена, объектное представление базы данных и всю логику для связи и обновления записей базы данных.
N-уровневая архитектура никогда не взаимодействует напрямую с уровнем доступа к данным. В трехуровневой архитектуре:
- Уровень представления представляет связанный пользовательский интерфейс,
- Бизнес-уровень содержит связанную логику и
- затем уровень доступа к данным.
Все данные передаются через средний уровень. Презентация <-> Бизнес <-> Данные.
Архитектура MVC (модель-представление-контроллер) имеет треугольную форму.
- View отправляет обновления контроллеру,
- Контроллер обновляет Модель и
- тогда View напрямую получает обновления от модели.
Модель (данные), представление (пользовательский интерфейс), контроллер (логика).
В трехуровневой модели все коммуникации должны проходить через средний уровень. Концептуально трехуровневая архитектура является линейной. Однако архитектура MVC [model-view-controller] является треугольной: представление отправляет обновления контроллеру, контроллер обновляет модель, а представление обновляется непосредственно из модели.