Я хотел бы знать, чем отличается 3-уровневая архитектура от MVC (Model, View Controller) в ASP.Net, поскольку мне кажется, что применяется та же архитектура.
В 3- х уровневых мы имеем User Services Layer, BusinessLayerи DataAccessLayer, с другой стороны , у нас есть Model, Viewи Controller. Это кажется той же архитектурой для меня.
Может ли кто-нибудь объяснить, что действительно отличается от двух архитектур, как каждый слой отличается друг от друга?
asp.net
asp.net-mvc
japzdivino
источник
источник
Ответы:
Это все равно, что спросить, в чем разница между яблоком и яблочным ядром. Эти две архитектуры не являются заменой друг другу. Я думаю, что более точное представление состоит в том, что 3-уровневая архитектура дополняет MVC.
Архитектура MVC
Модели: они представляют «материал» в вашем приложении. Этот слой стал немного размытым в последние годы, как я объясню позже.
Просмотры: пользовательский интерфейс. То, с чем взаимодействует пользователь.
Контроллеры: программный код, который отвечает пользователю и изменениям на уровне модели
3-х уровневая архитектура
С 3-уровневой архитектурой у вас есть слои с разными обязанностями.
Пользовательские сервисы: (или «сервисы» в целом) Этот уровень больше связан с координацией поиска и модификаций «модельного» уровня. Сложные, многошаговые действия выполняются здесь
Бизнес-уровень: представляет бизнес-правила, вписанные в программный код. То, что хочет «Бизнес», исполняется на этом уровне.
Уровень доступа к данным: один или несколько классов, отвечающих за доступ к постоянному хранилищу данных.
Единственная часть 3-уровневой архитектуры, которая пересекается с MVC, - это «Бизнес-уровень». «Модели» в MVC и «Бизнес-уровень» в 3-уровневой архитектуре пытаются достичь одной и той же цели.
«М» в MVC стало нечетким
«Модельный» слой в MVC расширился за последние годы. Из того, что я видел, есть две, возможно, три вида моделей:
Модели предметной области: они представляют собой «вещи», о которых заботится «Бизнес» - бизнес-домен. Эти классы содержат данные и все процедуры, которые работают с этими данными для обеспечения соблюдения бизнес-правил. Часто доменные модели привязаны к таблицам в базе данных. Кажется, это соответствует «бизнес-уровню» 3-уровневой архитектуры.
Модели представления: это классы, используемые для преобразования данных из моделей предметной области в нечто более приятное для просмотра. Это никуда не вписывается в трехуровневую архитектуру, поскольку модели представлений не реализуют бизнес-логику и не предоставляют какой-либо вид обслуживания или доступа к данным.
Бизнес-модели. В сложных приложениях возникает необходимость отделить модель домена от бизнес-логики. Бизнес-модели содержат данные и процедуры, работающие с этими данными для реализации бизнес-правил, а доменные модели переводятся в «Пакеты свойств» - объекты, которые просто содержат данные, но не содержат поведения. Доменные модели становятся еще одной формой объекта передачи данных между базой данных и приложением.
Нигде в MVC не упоминается доступ к данным. В некоторых случаях вы увидите, что доступ к данным относится к «модельному» слою MVC, который, как мы видели, больше не является прозрачным. Действительно, я вижу трехуровневую архитектуру в паре с MVC для создания целого приложения. Один увеличивает или улучшает другой:
Есть некоторые пересечения, но они в значительной степени разделены, и вместе используются, чтобы разъединить и изолировать различные компоненты большей системы.
источник
Нет, они не одинаковы.
MVC - это шаблон проектирования для структурирования кода пользовательского интерфейса. Он может использоваться в трехуровневой архитектуре, и в этом случае шаблон будет принадлежать уровню пользовательских услуг. Но его также можно использовать для пользовательского интерфейса в приложениях, которые не являются трехуровневыми, например, в калькуляторе без постоянного сохранения и, следовательно, без уровня доступа к данным.
В трехуровневой архитектуре с внешним интерфейсом MVC доменные объекты, используемые в качестве модели, будут объектами бизнес-уровня, но шаблон MVC на самом деле не определяет, какие объекты представляет модель, только их роль в шаблоне. является. Например, в варианте MVVM модели представляют собой адаптеры, определяемые пользовательским интерфейсом, поверх объектов домена. В этом случае даже модель относится к уровню обслуживания пользователей.
источник
Я знаю, что будет множество разных ответов, но я дам вам свой взгляд на это.
Это самый известный ответ в программной инженерии "Это зависит".
По сути, если вы посмотрите на это, помимо различных реализаций и теоретических различий, это очень похожие шаблоны с похожими потоками.
От того, что зависит, зависит приложение, которое вы создаете, в простом веб-приложении может быть только слой MVC, взаимодействующий через ORM с БД. Более сложный может иметь MVC, обрабатывающий интерфейс на уровне пользователя, с более сложными операциями, не связанными с пользователем, на уровне BL, с уровнем данных, состоящим из нескольких источников.
источник