Разница между 3-уровневой архитектурой и MVC (модель, контроллер представления) в ASP.Net

Я хотел бы знать, чем отличается 3-уровневая архитектура от MVC (Model, View Controller) в ASP.Net, поскольку мне кажется, что применяется та же архитектура.

В 3- х уровневых мы имеем User Services Layer, BusinessLayerи DataAccessLayer, с другой стороны , у нас есть Model, Viewи Controller. Это кажется той же архитектурой для меня.

Может ли кто-нибудь объяснить, что действительно отличается от двух архитектур, как каждый слой отличается друг от друга?

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

Архитектура MVC

• Модели: они представляют «материал» в вашем приложении. Этот слой стал немного размытым в последние годы, как я объясню позже.

• Просмотры: пользовательский интерфейс. То, с чем взаимодействует пользователь.

• Контроллеры: программный код, который отвечает пользователю и изменениям на уровне модели

3-х уровневая архитектура

С 3-уровневой архитектурой у вас есть слои с разными обязанностями.

• Пользовательские сервисы: (или «сервисы» в целом) Этот уровень больше связан с координацией поиска и модификаций «модельного» уровня. Сложные, многошаговые действия выполняются здесь

• Бизнес-уровень: представляет бизнес-правила, вписанные в программный код. То, что хочет «Бизнес», исполняется на этом уровне.

• Уровень доступа к данным: один или несколько классов, отвечающих за доступ к постоянному хранилищу данных.

Единственная часть 3-уровневой архитектуры, которая пересекается с MVC, - это «Бизнес-уровень». «Модели» в MVC и «Бизнес-уровень» в 3-уровневой архитектуре пытаются достичь одной и той же цели.

«М» в MVC стало нечетким

«Модельный» слой в MVC расширился за последние годы. Из того, что я видел, есть две, возможно, три вида моделей:

1. Модели предметной области: они представляют собой «вещи», о которых заботится «Бизнес» - бизнес-домен. Эти классы содержат данные и все процедуры, которые работают с этими данными для обеспечения соблюдения бизнес-правил. Часто доменные модели привязаны к таблицам в базе данных. Кажется, это соответствует «бизнес-уровню» 3-уровневой архитектуры.

2. Модели представления: это классы, используемые для преобразования данных из моделей предметной области в нечто более приятное для просмотра. Это никуда не вписывается в трехуровневую архитектуру, поскольку модели представлений не реализуют бизнес-логику и не предоставляют какой-либо вид обслуживания или доступа к данным.

3. Бизнес-модели. В сложных приложениях возникает необходимость отделить модель домена от бизнес-логики. Бизнес-модели содержат данные и процедуры, работающие с этими данными для реализации бизнес-правил, а доменные модели переводятся в «Пакеты свойств» - объекты, которые просто содержат данные, но не содержат поведения. Доменные модели становятся еще одной формой объекта передачи данных между базой данных и приложением.

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

• модели
  • Доменные модели (MVC / 3-уровневый)
  • Просмотр моделей (MVC)
  • (опционально) бизнес-модели (MVC / 3-х уровневый)
• Просмотры (MVC)
• Контроллеры (MVC)
• Доступ к данным (3 уровня)
• Услуги (3 уровня)

Есть некоторые пересечения, но они в значительной степени разделены, и вместе используются, чтобы разъединить и изолировать различные компоненты большей системы.

Нет, они не одинаковы.

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

В трехуровневой архитектуре с внешним интерфейсом MVC доменные объекты, используемые в качестве модели, будут объектами бизнес-уровня, но шаблон MVC на самом деле не определяет, какие объекты представляет модель, только их роль в шаблоне. является. Например, в варианте MVVM модели представляют собой адаптеры, определяемые пользовательским интерфейсом, поверх объектов домена. В этом случае даже модель относится к уровню обслуживания пользователей.

Я знаю, что будет множество разных ответов, но я дам вам свой взгляд на это.

Это самый известный ответ в программной инженерии "Это зависит".

По сути, если вы посмотрите на это, помимо различных реализаций и теоретических различий, это очень похожие шаблоны с похожими потоками.

От того, что зависит, зависит приложение, которое вы создаете, в простом веб-приложении может быть только слой MVC, взаимодействующий через ORM с БД. Более сложный может иметь MVC, обрабатывающий интерфейс на уровне пользователя, с более сложными операциями, не связанными с пользователем, на уровне BL, с уровнем данных, состоящим из нескольких источников.