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


142

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

ура

Ответы:


94

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

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

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


56
N-уровень также является шаблоном проектирования, для создания 3-уровневой системы не требуется 3 сервера, фактически можно создать n-уровневую систему, используя один файл, разделяя каждый уровень концептуальной концепцией.
Магалланес

6
Уровень в основном подразумевает, что межпроцессное взаимодействие происходит обычно по сетевому каналу. Я не согласен с тем, что процесс разработки кода внутри процесса (не говоря уже о том же файле) представляет собой многоуровневый подход к проектированию. Конечно это ИМХО. «Сервер» подразумевает, что машина может запускать несколько процессов на одном компьютере; и они, вероятно, могут даже говорить в локальной сети.
Зак

2
Все обсуждаемые форматы являются примерами трехслойного дизайна. Не путайте разницу между слоем и уровнем. Это правда, что вы можете запустить более одного уровня на физическом механизме (например, вы разделяете большой сервер с помощью гипервизоров), но суть здесь в том, что N-уровень соответствует физическому сетевому переходу (например, TCP / IP). Локально вам будет эффективнее использовать именованные каналы, но, опять же, если вы работаете в той же системе, вы конкурируете за память и вычислительную мощность. Все это является причиной, по которой стоит рассмотреть возможность изоляции представления, бизнес-логики и доступа к данным и базы данных на разных компьютерах.
Зак Яннсен

1
Я бы порекомендовал всем, кто читает этот вопрос, прочитать другие ответы, этот ответ неточный
keisar

@magallanes, перейдите к «Zak», сначала нам нужно прояснить разницу между Tier и Layer. Вот очень хорошая статья codeproject, в которой есть четкое объяснение
Irf

42

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

Client <-> Middle <-> Data

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

     Middle
     ^    |
     |    v
Client <- Data

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

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

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


13
в MVC может модель взаимодействовать напрямую с клиентом (view) ??? Я так не думаю!
PalAlaa

6
@ Алаа, я согласен, и поэтому я думаю, что это относится к потоку данных. Обновление: я только что зарегистрировался в Википедии, и Модель может взаимодействовать с Видом через наблюдателей (не напрямую).
недействительно

1
В MVC: архитектура MVC является треугольной: представление отправляет обновления контроллеру, контроллер обновляет модель, а представление обновляется непосредственно из модели. В трехуровневой архитектуре: трехуровневая архитектура означает, что уровень клиента никогда не связывается напрямую с уровнем данных. В трехуровневой модели все коммуникации должны проходить через средний уровень
кетан италия

1
Здесь, если Middle является контроллером, то связь между Middle, Client и Middle, Data является двунаправленной, а не однонаправленной, как описано в ans. Контроллер передает данные в модель, и модель возвращает обратно обновленные данные в контроллер, который затем возвращает их в браузер. после прохождения через вид.
Дракон

30

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

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


11
Звучит хорошо, но я не верю, что «представление обновляется непосредственно из модели» - это хорошая идея. Нет смысла использовать Контроллер для обновлений и вставок, но не для селекторов и фильтров, и я не вижу смысла разделять проблемы только для того, чтобы связать представление с моделью в любом случае! Вывод - MVC - еще одно из этих запутываний, созданных .... есть предположение. Я не помню, чтобы 3-уровневый уровень ограничивался «архитектурой системы» или «дизайном приложения». Центральная концепция - это разделение интересов .
Сэм

1
Это будет зависеть от того, что вы делаете. Приложение MVC для приложения iOS (которое, вероятно, не позволит обновлять представление непосредственно из модели) будет отличаться от веб-приложения (которое может). MVC - это парадигма, а не абсолютный способ ведения дел.
Дэйв Кантер

2
@ Сэм полностью согласен. Слишком много жаргона для интуитивного понятия.
smwikipedia

1
звучит хорошо, не работает. Википедия не является основным источником правды
ACV

Это то, как вы истолковываете правду, и опять же, это зависит от ваших целей
Xinus

17

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


3
Я думаю, что это лучший ответ, особенно если учесть, что MVC действительно сфокусирован на пользовательском интерфейсе и может быть вашим уровнем пользовательского интерфейса в трехуровневом дизайне. Диаграмма в ссылке демонстрирует это очень хорошо.
Алекс

5

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

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


5

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

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

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

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


1
Я думаю, что, как сказано выше, MVC является треугольным, поэтому представление иногда может напрямую взаимодействовать
ychaouche

5

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


4

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


3

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

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

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

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


Если mvc ничего не использует для данного сценария, то есть ли какие-либо преимущества mvc по сравнению с n-уровневой архитектурой.
Дракон

2

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


1

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


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


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


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


1

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


На самом деле это не MVC, это MVVMC. Я вижу, что MVC или MVVMC - это просто уровень представления, потому что я вижу, что контроллер - это просто промежуточное ПО между представлениями и BLL. Вот как я бы поддерживал это, чтобы я мог использовать BLL в качестве библиотеки для создания пользовательского интерфейса для разных платформ. Это своего рода aspx.cs с поддержкой asmx. Я иногда чувствую, что MVC - это плохой способ организации файлов в папке проекта, его немного сложно понять, потому что все контроллеры будут на одном уровне и представления в подпапках. Я также могу создавать подпапки для контроллеров, но это дублирует работу.
Нитин Б
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.