MVC против n-уровневой архитектуры

Мне было интересно, в чем именно заключается разница между MVC (который является архитектурным шаблоном) и n-уровневой архитектурой для приложения. Я искал это, но не мог найти простое объяснение. Может быть, я немного наивен в понятиях MVC, поэтому, если кто-то сможет объяснить разницу, это было бы здорово.

ура

N-уровневая архитектура обычно имеет каждый уровень, разделенный сетью. То есть уровень представления находится на некоторых веб-серверах, затем он обращается к внутренним серверам приложений по сети для бизнес-логики, затем он обращается к серверу базы данных, снова по сети, и, возможно, сервер приложений также вызывает некоторые удаленные службы ( скажем Authorize.net для обработки платежей).

MVC - это шаблон разработки программного обеспечения, в котором разные части кода отвечают за представление модели, представления и контроллера в некотором приложении. Эти две вещи связаны, потому что, например, уровень модели может иметь внутреннюю реализацию, которая вызывает базу данных для хранения и извлечения данных. Контроллер может находиться на веб-сервере и удаленно вызывать серверы приложений для извлечения данных. MVC абстрагируется от деталей реализации архитектуры приложения.

N-ярус просто относится к физической структуре реализации. Эти два иногда путаются, потому что проект MVC часто реализуется с использованием N-уровневой архитектуры.

Если бы 3-х уровневый дизайн был таким:

Client <-> Middle <-> Data

скороговоркой MVC будет:

     Middle
     ^    |
     |    v
Client <- Data

Означающий, что:

• в 3-уровневом эквиваленте связь между уровнями является двунаправленной и всегда проходит через средний уровень
• в эквиваленте MVC связь является однонаправленной ; мы могли бы сказать, что каждый «слой» обновляется тем, который слева, и, в свою очередь, обновляет тот, который справа - где «слева» и «справа» являются просто иллюстративными

PS Клиент будет вполне Посмотреть и Средний контроллер

Это то, что говорят о n-уровневой архитектуре

На первый взгляд, три уровня могут показаться похожими на концепцию MVC (Model View Controller); однако топологически они разные. Основное правило в трехуровневой архитектуре - уровень клиента никогда не связывается напрямую с уровнем данных; в трехуровневой модели все коммуникации должны проходить через промежуточный уровень. Концептуально трехуровневая архитектура является линейной. Однако архитектура MVC имеет треугольную форму: представление отправляет обновления контроллеру, контроллер обновляет модель, а представление обновляется непосредственно из модели.

Единственное сходство состоит в том, что эти две модели имеют три прямоугольника на своих диаграммах. Принципиально они совершенно разные по своему применению. На самом деле это не выбор между шаблоном, который нужно использовать, но оба шаблона могут быть вредно использованы вместе. Вот хорошее сравнение двух: http://allthingscs.blogspot.com/2011/03/mvc-vs-3-tier-pattern.html

Основное правило в трехуровневой архитектуре - уровень клиента никогда не связывается напрямую с уровнем данных; в трехуровневой модели все коммуникации должны проходить через промежуточный уровень.

Это линейная архитектура. Это решает вопрос о том, как передавать информацию между пользователем и базой данных. Где, поскольку MVC является треугольной архитектурой: представление отправляет обновления контроллеру, контроллер обновляет модель, а представление обновляется непосредственно из модели. Здесь рассматриваются вопросы о том, как пользовательский интерфейс управляет компонентами на экране.

Средство @Cherry Middle больше похоже на обработчик запросов или перенаправитель в MVC Pattern.

Я хотел бы объяснить немного о MVC, по мне, Model View Controller работает следующим образом.

1. Клиент инициирует сеанс, запрашивая любую услугу.
2. Этот запрос принимается и обрабатывается контроллером (обработчик запросов, перенаправитель и т. Д.)
3. Контроллер обрабатывает базовую информацию по запросу и перенаправляет ее в соответствующую модель, которая может заполнить запрос данных.
4. Модель заполняет запрос в соответствии с параметрами, переданными контроллером, и отправляет результаты обратно в контроллер. (Примечание: здесь я хотел бы пояснить, что данные не возвращаются напрямую клиенту в истинной архитектуре MVC, а заполняются и возвращаются контроллеру.)
5. Контроллер, чем отправить эти данные в View (клиент).
6. Клиент имеет запрошенную услугу перед ним.

Это все о MVC, что я знаю.

Дай себе перерыв. И не ограничивайте себя определенными шаблонами при решении реальных проблем. Просто запомните некоторые общие принципы, одним из которых является ОТДЕЛЕНИЕ ЗАБОЛЕВАНИЙ .

Помимо линейности, еще одно существенное отличие, которое здесь недостаточно подчеркивалось, заключается в том, что в N-уровневой модели N не обязательно является 3-уровневым! Чаще всего он реализуется в виде трех уровней (представление, приложение, данные), а средний уровень имеет два подуровня (бизнес-логика и доступ к данным). Кроме того, модель в MVC может содержать как данные, так и бизнес-логику для манипулирования данными, тогда как в n-ярусах они будут отдельными уровнями.

N-уровневая архитектура лучше всего определяется с помощью диаграммы развертывания.

Архитектура MVC лучше всего определяется с использованием диаграммы последовательности.

2 не являются одинаковыми и не связаны, и вы можете объединить две архитектуры вместе. Многие компании предприняли шаги для создания архитектуры N Tier'd не только для развертывания и масштабируемости, но и для повторного использования кода.

Например, ваши объекты Business Entity могут потребляться настольным приложением, веб-службой, предоставляемой клиенту, веб-приложением или мобильным приложением. Простое использование подхода MVC не поможет вам вообще что-либо использовать.

Вывод: N-уровень - это архитектура, MVC - шаблон проектирования. Это один и тот же метафора, применяемый в двух разных областях.

Джерри: Вот простой пример того, как они связаны:

Уровень 1 - состоит из моделей, которые взаимодействуют с уровнем 2 через какую-либо сетевую службу или аналогичные контроллеры для обработки проверки входных данных, расчетов и других вещей, относящихся к представлениям. И он содержит сами представления, конечно, которые могут быть графическим интерфейсом в настольном приложении или веб-интерфейсом в веб-приложении.

Уровень 2 - содержит какой-либо вид обслуживания или другой способ получения сообщений с уровня 1. Не знает / не должен знать о уровне 1, поэтому может отвечать только на вызовы сверху - никогда ничего не запрашивать сам по себе. Также содержит всю бизнес-логику.

Уровень 3 - содержит модель домена, объектное представление базы данных и всю логику для связи и обновления записей базы данных.

В трехуровневой модели все коммуникации должны проходить через средний уровень. Концептуально трехуровневая архитектура является линейной. Однако архитектура MVC [model-view-controller] является треугольной: представление отправляет обновления контроллеру, контроллер обновляет модель, а представление обновляется непосредственно из модели.