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

Ответ 1

3-уровневый - Стиль архитектуры и MVC - это Шаблон дизайна.

так отличается в этом.

но мы могли бы использовать шаблон mvc в трехуровневом архитектурном стиле.

так:

Уровень представления: "Контроллеры и представления" из шаблона MVC.

Бизнес-уровень: "Модель (данные)" из шаблона MVC.

Уровень доступа к данным: исходный уровень доступа к данным.

Ответ 2

В больших приложениях MVC представляет собой уровень представления только архитектуры N-уровня. Представления моделей и контроллеры относятся только к презентации и используют средний уровень для заполнения моделей данными из уровня данных.

MVC также может использоваться как целая трехуровневая архитектура, где Views - ваша презентация, контроллеры - это ваша бизнес-логика, а модели - ваш уровень данных (обычно генерируемый DAL, например Entity Framework).

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

Ответ 3

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

Архитектура 3-уровня обычно развертывается как 3 отдельных процесса на 3 отдельных сетевых узлах. Но MVC предназначен для развертывания в виде единого процесса в одной сети node. (например, настольное приложение)

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

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

Ответ 4

Я использую другой подход по сравнению с тем, что сказал Майкл в своем ответе.

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

Помните, что вам не нужно иметь модель внутри одного и того же проекта (говоря о ASP.NET MVC). Он может находиться в совершенно другом проекте и может по-прежнему действовать как модель приложения

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

Итак, мы можем сказать, что MVC делает два (третий может быть слоем данных, который не является частью архитектуры MVC как таковой) из трех уровней трехуровневой архитектуры.

Спасибо.

Ответ 5

Что такое трехуровневая архитектура?

Трехуровневый уровень (layer) представляет собой клиент-серверную архитектуру, в которой пользовательский интерфейс, бизнес-процесс (бизнес-правила) и хранение данных и доступ к данным разрабатывается и поддерживается как независимые модули или чаще всего на отдельных платформах. В основном, есть 3 уровня, уровень 1 (уровень представления, уровень GUI), уровень 2 (бизнес-объекты, уровень бизнес-логики) и уровень 3 (уровень доступа к данным). Эти уровни можно разрабатывать и тестировать отдельно.

DAL - уровень доступа к данным (у него есть процесс чтения и выполнения Connectionstring и Data)

BOL - Уровень объекта Bussiness (у него есть запросы)

UI - Пользовательский интерфейс (формы и код)

Подробнее: 3-я архетика уровня

Ответ 6

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

(См. "Сравнение с архитектурой MVC" на http://en.wikipedia.org/wiki/3-tier_architecture)

Ответ 7

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

Я не разрабатываю часть определений, но в двух словах:

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

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

Ответ 8

Каждое приложение имеет один из следующих слоев: 1) Уровень презентации или уровень пользовательского интерфейса 2) Уровень бизнес-уровня или бизнес-логики 3) Уровень доступа к данным или уровень данных

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

несколько раз мы требуем больше слоев вышеуказанного типа и более mechines, тогда он называется N-уровневым

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

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

Ответ 9

Между ними нет никакой связи. MVC - это шаблон слоя представления. Весь Model-View-Controller существует в уровне представления.

• Модель - это данные хранения объекта (обычно только VO), которые представлены View или, заполнены из View.

• Контроллер - это то, что получает запрос (и может заполнять модель) и вызывает уровень сервиса. Затем получает другую (или такую ​​же) модель и отправляет ее обратно в View.

• Просмотр - это то, что отображает модель, и предоставляет компоненты для захвата ввода пользователя. (Обычно это шаблонный движок в веб-приложениях или компонентах пользовательского интерфейса в настольном приложении).

Говоря о 3-уровневом (или n-уровневом) приложении, мы говорим об архитектуре всего приложения, которое состоит из уровня представления (весь MVC), уровня обслуживания (бизнес-классы) и уровня доступа к данным.

Слой обслуживания (и все за ним) скрыты за контроллерами MVC.

Ответ 10

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

Я ненавижу код, написанный так: термин MVC, должно быть, был разработан, чтобы запутать рекрутеров HR, думая, что более старые программисты (которые знают это как "3-ярус" ) не соответствуют заданию.

Ответ 11

В MVC: архитектура MVC треугольная: представление отправляет обновления контроллеру, контроллер обновляет модель, и представление обновляется непосредственно из модели

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

Викас Джоши Инженер-программист

Ответ 12

• 3-уровневая линейная архитектура. (Уровень представления → Логический уровень → Уровень данных, затем Уровень данных → Логический уровень → Уровень представления) Но MVC представляет собой треугольную архитектуру. (Просмотр и модель управления обновлением. update View.)
• MVC может включать в уровень представления (мобильные приложения, Angular, такие как js frameworks и т.д.) и уровень логики (J2EE, Laravel и т.д.) в архитектуре с 3 уровнями.
• Слои в 3 уровня могут реализовываться в разных сетевых узлах. Но обычно элементы MVC реализуются в одних и тех же сетевых узлах.

Ответ 13

Я не думаю, что MVC изменит что-либо или поможет вам построить лучшую или надежную систему. Архитектура 3 уровня - это успешная и достаточная система. Я/вы можете создать в нем очень всеобъемлющую и надежную систему. Мы все знаем, что сложный или реальный веб-сайт требует много взаимодействия между всеми слоями. Я лично считаю, что php по этой причине имеет преимущество над .net. Если вы спросите у дерзкого жопа высокомерного программиста, чтобы создать простую систему форумов в .net, он поцарапает его голову, над которой элемент управления будет использоваться для рендеринга. Затем он объединит сетку данных с некоторым ретранслятором... Но позже, если вы просто попросите добавить раздел комментария или изображение, он будет похож на то, как я это делаю? С другой стороны, в php... U можно смешивать в html с кодом сервера, чтобы легко достичь любого уровня представления... Поэтому не хвастайтесь архитектурой, поскольку у них одинаковые преимущества и недостатки. Но спросите, что вы построили?