Что лучше: разработка веб-проекта в MVC или N-уровневой архитектуре?

Question

Я уже задавал подобный вопрос и получил убедительный ответ?

Чем отличается разработка веб-сайта в MVC и 3-уровневой или N-уровневой архитектуре?

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

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

Каков наилучший шаблон проектирования для проектирования интерфейса веб-страницы?

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

Я думаю, что ASP.net использовал 3-уровневую архитектуру при разработке приложений или веб-приложений. Где в качестве фреймворков, таких как Zend, Symphony, они используют MVC.

Я просто хочу придерживаться шаблона, который лучше всего подходит для разработки WebProject? Может быть, это очень глупая путаница? Но если бы кто-то мог устранить эту путаницу, это было бы очень здорово?

Answer 1

Они не являются взаимоисключающими. Шаблон Model-View-Controller действительно является шаблоном проектирования пользовательского интерфейса, и он касается логических, а не физических уровней.

Чаще всего я слышу «n-уровневую архитектуру», используемую для описания фактического физического разделения уровней приложения. Например, система, в которой пользовательский интерфейс выполняется в одном процессе, обменивается данными с прикладным уровнем (возможно, с помощью обмена сообщениями или веб-служб), который выполняется в другом процессе (возможно, на другом сервере), который, в свою очередь, обращается к уровню данных, который выполняется в еще одном процессе (обычно это сервер базы данных).

Это описание может быть особенно запутанным, поскольку «логика приложения» может означать несколько вещей: в n-уровневой системе это обычно означает бизнес-логика - в отличие от логики пользовательского интерфейса ( например, какие виджеты включены, когда пользователь устанавливает определенный флажок).

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

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

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

Answer 2

Я просто хочу придерживаться шаблона, который лучше всего подходит для WebProject Разработка? Может быть, это очень глупая путаница? Но если бы кто-то мог очистить эту путаницу, это было бы очень здорово?

Я думаю, что ваша путаница заключается в двух областях:

1) Предположение, что для каждой проблемы есть одно решение.

Требования вашего проекта будут определять, какое решение лучше.

2) Определение MVC применительно к Интернету отличается от того, которое изначально применялось к настольным приложениям.

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

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

Answer 3

Возможно, вы захотите ознакомиться с Руководством по архитектуре приложений Microsoft. В нем содержится хороший обзор доступных технологий Microsoft с точки зрения архитектуры.Главы, которые могут вас заинтересовать:

• Глава 21 Разработка веб-приложений
• Приложение B: Матрица технологии презентаций
• Приложение C: Матрица технологий доступа к данным

А что лучше?Вы должны ответить на это самостоятельно.Сделайте несколько примеров проектов, используя MVC, WebForms и т. Д.

Answer 4

MVC на веб-основе сильно отличается от традиционного настольного MVC. Модель просто не имеет возможности обновить представление, потому что сеть (по большей части) не имеет состояния.

Даже если вы используете AJAX для опроса сервера каждые пару секунд для проверки обновлений модели, это все равно не будет «истинным» MVC, поскольку это не модель, уведомляющая представление, а контроллер, постоянно «запрашивающий» модели.

Извлеченный урок заключается в том, что на самом деле не имеет значения, что вы называете своей архитектурой. Существует так много вариантов уровня MVC / 3, что обычно люди просто смешивают их под одеялом «MVC». И все это подходит для веб-разработки. Я просто не могу придумать какого-либо практического способа, чтобы Модель фактически уведомляла View через программирование на стороне сервера (по крайней мере, в PHP). Если вам нужно такое поведение, вы должны писать настольное приложение. Просто напишите, что для вас естественно, и не увлекайтесь дискуссиями по терминологии. Посмотрите, что делают некоторые из хорошо известных фреймворков, таких как CodeIgniter, Kohana, Symfony, CakePHP и Zend, и выберите, какие функции или шаблоны дизайна вам понравятся.

Answer 5

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

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

Answer 6

Почему бы не использовать оба? В данный момент я занят разработкой проекта с использованием шаблона MVP и N-уровневой архитектуры. Я использую шаблон MVP в проекте пользовательского интерфейса, т.е. веб-сайт. Все данные, которые необходимо показать и использовать на веб-сайте, передаются из веб-сервиса. Этот веб-сервис подключен к бизнес-уровню (BLL), который подключен к уровню доступа к данным (DAL). DAL подключен к базе данных с помощью Entity Framework.

Так что в этом проекте я использую их обоих. Используя MVP вместо MVC, хотя. Таким образом, интерфейсный проект (веб-сайт) не должен делать сложные вещи, он только передает некоторые данные, полученные от веб-службы. Мне потребовалось некоторое время, чтобы настроить, но это работает довольно чудесно.

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