MVC против 3-х уровневой архитектуры?
В чем принципиальная разница между MVC и 3-уровневой архитектурой?
13 ответов
Трехуровневый - это стиль архитектуры, а MVC - это шаблон проектирования.
В этом все иначе.
но мы могли бы использовать шаблон MVC в стиле 3-уровневой архитектуры.
так:
Уровень представления: "Контроллеры и представления" из MVC Pattern.
Бизнес-уровень: "Модель (Данные)" из MVC Pattern.
Уровень доступа к данным: исходный уровень доступа к данным.
В более крупных приложениях MVC - это уровень представления только N-уровневой архитектуры. Представления моделей и контроллеры связаны только с представлением и используют средний уровень для заполнения моделей данными из уровня данных.
MVC также можно использовать как всю трехуровневую архитектуру, где Views - это ваша презентация, Controllers - ваша бизнес-логика, а Models - ваш уровень данных (обычно генерируемый DAL, например Entity Framework).
В идеале, хотя вы хотите, чтобы ваши контроллеры были тонкими и тупыми, передавая логику "бизнес-компоненту", который по сути стал бы вашим средним уровнем.
В трехуровневой архитектуре связь между уровнями является двунаправленной. В MVC связь является однонаправленной; мы могли бы сказать, что каждый "слой" обновляется тем, что слева, и, в свою очередь, обновляет тот, который справа - где "слева" и "справа" являются просто иллюстративными.
Трехуровневая архитектура обычно разворачивается как 3 отдельных процесса на 3 отдельных сетевых узлах. Но MVC предназначен для развертывания как единого процесса в одном сетевом узле. (как настольное приложение)
Бизнес-уровень в 3-х уровнях обычно содержит различные уровни, реализующие известные шаблоны, такие как бизнес-делегат, бизнес-фасад, бизнес-объект, локатор служб, объект передачи данных и т. Д. Но MVC - это сам шаблон проектирования, который используется на уровне представления.
Целью 3-уровневого является отделение бизнес-логики от клиента и базы данных, поэтому обеспечить несколько клиентских протоколов, высокую масштабируемость, гетерогенный доступ к данным и т. Д. Но основная цель MVC состоит в том, что изменения реализации в одной части не требуют изменений в другой,
Там нет никаких отношений между двумя. MVC - это шаблон уровня представления. Весь Model-View-Controller существует на уровне представления.
Модель - это объект, содержащий данные (обычно просто VO), которые представлены View или, заполненные из View.
Контроллер - это то, что получает запрос (и может заполнять модель) и вызывает уровень обслуживания. Затем получает другую (или ту же) модель и отправляет ее обратно в View.
Представление - это то, что отображает модель и предоставляет компоненты для захвата пользовательского ввода. (Обычно это шаблонизатор в веб-приложениях или компоненты пользовательского интерфейса в настольном приложении).
Говоря о 3-уровневом (или n-уровневом) приложении, мы говорим об архитектуре всего приложения, которая состоит из уровня представления (всего MVC), уровня обслуживания (бизнес-классов) и уровня доступа к данным.
Сервисный уровень (и все за этим) скрыто за контроллерами MVC.
Я придерживаюсь другого подхода по сравнению с тем, что сказал Майкл в своем ответе.
Контроллеры никогда не должны быть вашей бизнес-логикой. Для меня бизнес-логика относится к модельному слою. И хотя, представления (и в некоторой степени контроллеры) и часть уровня представления, модель никогда не является частью этого в приложении MVC. Модель должна быть сердцем и душой приложения MVC, и именно в этом и заключается суть Domain Driven Design, который может быть легко реализован в приложении MVC.
Пожалуйста, помните, что вам не нужно иметь модель внутри одного проекта (если говорить о ASP.NET MVC). Он может находиться в совершенно другом проекте и все еще может служить моделью для приложения.
Приложение MVC, выступающее только в качестве уровня представления, может работать в огромном проекте со многими уровнями, но оно никогда не может выступать в качестве уровня представления только в 3-уровневой архитектуре, о чем спрашивал спрашивающий.
Таким образом, мы можем сказать, что MVC создает два (третьим может быть уровень данных, который на самом деле не является частью архитектуры MVC) из трех уровней 3-уровневой архитектуры.
Благодарю.
ИМО не существует прямого сравнения между 3-уровневой архитектурой и MVC. Оба используются в сочетании, и поэтому мы склонны видеть их через одну и ту же линзу. Концептуально их не нужно использовать вместе. Я мог бы иметь 3-уровневую архитектуру, которая не использует то, что может предложить MVC.
Я не разрабатываю часть определений, но в двух словах:
3-уровневый подход - это программная архитектура, в которой пользовательский интерфейс, бизнес-процесс являются логикой, а уровень данных разрабатывается независимо, чаще всего на отдельных платформах.
MVC с течением времени превратилась из программного шаблона в архитектурный и встречается во всех основных средах.
Что такое 3-х уровневая архитектура?
Трехуровневый (уровень) - это клиент-серверная архитектура, в которой пользовательский интерфейс, бизнес-процесс (бизнес-правила) и хранилище данных и доступ к данным разрабатываются и поддерживаются как независимые модули или чаще всего на отдельных платформах. По сути, существует 3 уровня: уровень 1 (уровень представления, уровень графического интерфейса пользователя), уровень 2 (бизнес-объекты, уровень бизнес-логики) и уровень 3 (уровень доступа к данным). Эти уровни могут быть разработаны и протестированы отдельно.
DAL - Уровень доступа к данным (он имеет строку подключения и процесс чтения и выполнения данных)
BOL - слой бизнес-объектов (в нем есть запросы)
Пользовательский интерфейс - пользовательский интерфейс (формы и код позади)
Более подробная информация: 3-х уровневая архитектура
Каждое приложение имеет один из следующих уровней: 1) уровень представления или уровень пользовательского интерфейса 2) бизнес-уровень или уровень бизнес-логики 3) уровень доступа к данным или уровень данных
3- уровневая архитектура обычно имеет каждый слой, разделенный сетью. То есть уровень представления находится на некоторых веб-серверах, затем он взаимодействует с внутренними серверами приложений по сети для бизнес-логики, затем - с сервером базы данных, снова по сети, и, возможно, сервер приложений также обращается к некоторому удаленному услуги (скажем Authorize.net для обработки платежей).
иногда нам требуется больше слоев вышеуказанного типа и больше механизмов, чем это называется N-ярусом
MVC - это шаблон проектирования программирования, в котором различные части кода отвечают за представление модели, представления и контроллера в некотором приложении. Эти две вещи связаны, потому что, например, уровень модели может иметь внутреннюю реализацию, которая вызывает базу данных для хранения и извлечения данных. Контроллер может находиться на веб-сервере и удаленно вызывать серверы приложений для извлечения данных. MVC абстрагируется от деталей реализации архитектуры приложения. Модель, на основе которой мы хотели построить. View означает UI приложения. Contol Означает логику, управляющую приложением.
Трехуровневый просто относится к физической структуре реализации. Эти два иногда путаются, потому что проект MVC часто реализуется с использованием 3-уровневой архитектуры.
3-уровневая архитектура является линейной, когда клиентский уровень фактически никогда не связывается с уровнем данных - вся связь проходит через средний уровень. MVC, с другой стороны, является более треугольным, когда представление отправляет обновления контроллеру и получает обновления от модели, а контроллер обновляет модель.
(См. "Сравнение с архитектурой MVC" на http://en.wikipedia.org/wiki/3-tier_architecture)
В MVC: архитектура MVC является треугольной: представление отправляет обновления контроллеру, контроллер обновляет модель, а представление обновляется непосредственно из модели
В трехуровневой архитектуре: трехуровневая архитектура означает, что клиентский уровень никогда не связывается напрямую с уровнем данных. В трехуровневой модели все взаимодействие должно проходить через средний уровень.
Викас Джоши Инженер-программист
Мой опыт показывает, что MVC - это просто еще один "причудливый" термин для плохо написанного 3-уровневого уровня, в котором часть взаимодействия переходит на бизнес-уровни, и, таким образом, на уровне клиента и / или уровня данных также смешаны бизнес-правила.
Я ненавижу код, написанный таким образом. Термин MVC, должно быть, был разработан, чтобы запутать HR-рекрутеров в мысли, что старшие программисты (которые называют его "3-уровневым") не подходят для работы.
- 3-х уровневая линейная архитектура. (Уровень представления -> Уровень логики -> Уровень данных, затем Уровень данных -> Уровень логики -> Уровень представления) Но MVC является треугольной архитектурой. (Управление обновлением View и Model. Обновление модели View.)
- MVC может включать в уровень представления (мобильные приложения, Angular, такие как js frameworks и т. Д.) И логический уровень (J2EE, Laravel и т. Д.) В 3-уровневой архитектуре.
- Уровни в 3 уровня могут быть реализованы в разных узлах сети. Но обычно элементы в MVC реализуются в одних и тех же сетевых узлах.
Я не думаю, что MVC что-то изменит или поможет вам построить лучшую или надежную систему. 3-х уровневая архитектура является успешной и достаточной системой. Я / вы можете построить очень всеобъемлющую и надежную систему в нем. Мы все знаем, что сложный или реальный сайт требует много взаимодействия между всеми слоями. Я лично считаю, что php по этой причине имеет преимущество над.net. Если вы попросите занудного программиста, занудного осла, создать простую систему форумов в.net, он почесывает голову над тем, какой контроль использовать для его рендеринга. Затем он объединит сетку данных с некоторым повторителем... Но позже, если вы просто попросите добавить секцию комментариев или изображение, он будет похож на то, как, черт возьми, я это делаю? С другой стороны, в php... U можно смешивать в html с серверным кодом, чтобы легко достичь любого уровня представления... Так что не хвастайтесь архитектурой, так как она имеет одинаковые преимущества и недостатки. Но спросите, что вы построили?