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

Трехуровневый - это стиль архитектуры, а MVC - это шаблон дизайна.

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

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

so:

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

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

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

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

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

Хотя в идеале вы хотите, чтобы ваши контроллеры были тонкими и тупыми, передав логику «бизнес-компоненту», который, по сути, стал бы вашим средним уровнем.

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

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

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

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

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

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

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

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

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

Спасибо.

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

• Модель - это объект, содержащий данные (обычно просто виртуальные объекты), которые представлены в представлении или заполняются из представления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 3-х уровневая линейная архитектура. (Уровень представления -> Уровень логики -> Уровень данных, затем уровень данных -> Уровень логики -> Уровень представления) Но MVC - это треугольная архитектура. (Управляйте обновлением View и Model. Model update View.)
• MVC может включать в себя уровень представления (мобильные приложения, Angular, такие как js-фреймворки и т. Д.) И уровень логики (J2EE, Laravel и т. Д.) В трехуровневой архитектуре.
• Уровни 3-го уровня могут быть реализованы в разных сетевых узлах. Но обычно элементы в MVC реализуются в одних и тех же сетевых узлах.

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