Могу ли я сказать, что MVP = 3 Tier Archi?
В последние несколько дней я искал оптимальную архитектуру для моего нового веб-приложения, которое было бы разработано в ASP.Net с использованием C#. До сих пор я только нахожу и изучаю следующие 3
- Трехуровневая архитектура (Примечание. Под уровнем я подразумеваю логический уровень)
- Контроллер модельного представления (MVC)
- Ведущий модели (MVP)
Теперь мои вопросы:
1) Насколько я понимаю, 3 уровня архитектуры и MVP могу ли я сказать, что MVP и 3 уровня это одно и то же? Если нет, то в чем разница между обоими? (Примечание: я нахожу разницу только между MVC и MVP или MVC и 3-х уровнями Archi, но никто не обращает внимания на различия между MVP и 3-х уровнями Archi)
2) Я обнаружил только три архитектурных варианта, есть ли другие варианты? (Примечание: здесь я хочу только варианты общей архитектуры веб-приложения, как указано выше 3)
3 ответа
С точки зрения архитектуры программного обеспечения; мы используем термины, потому что термины что-то значат. Когда вы используете такой термин, как "3-х уровневый", вы должны использовать его там, где он соответствует предполагаемому и понятному значению. Все виды вещей можно считать "трехуровневыми" просто благодаря наличию трех отдельных компонентов. Но если бы вы использовали этот термин для описания MVP, вы бы вводили в заблуждение другого человека. Почему бы просто не сказать "MVP"?
3-уровневый обычно относится к трем физическим уровням. И у Википедии есть отличная статья об этом здесь.
Со связанной схемой:
Ни MVP, ни MVC не исключают использование этих трех физических уровней. На самом деле, простое создание приложения в виде приложения "MVC" (или "MVP") больше ничего не проясняет. Например, это может быть MVC на стороне сервера (как в ASP.NET MVC) или MVC на стороне клиента с Javascript, или оба!
Насколько ваш вопрос об архитектурных вариантах; игровое поле довольно широко открыто. Выбор, который вы делаете, обычно зависит от ряда факторов, которые вы должны собирать во время сбора требований приложения.
Часто вы должны сделать компромисс между масштабируемостью и сложностью. Тем не менее, ряд новых технологий делает эту сделку незначительной - и я бы посоветовал всем, кто начинает новый проект, серьезно их рассмотреть (некоторые обсуждаются ниже).
Почти всегда лучше иметь физически выделенный уровень данных (SQL, Mongo, Azure, Amazon, на ваше усмотрение) и выделенный масштабируемый логический уровень (обычно реализуемый в наши дни как сервисы WCF в среде.NET).
Чаще всего люди присоединяются к своему веб-сайту и логическим уровням... но это не обязательно так. Иногда имеет смысл иметь физический уровень исключительно для веб-служб, которые доступны только для уровня вашего веб-сайта. Опять же, все зависит от ситуации.
Что касается логических уровней (в пределах вашего логического уровня), почти всегда лучше иметь какой-то уровень доступа к данным (DAL), модель в коде (реализованную вручную или через что-то вроде LINQ-to-Entities), и выделенный слой бизнес-логики.
В наши дни все больше и больше людей, похоже, прибегают к классическим HTML и Javascript (с помощью таких вещей, как JQuery, Prototype, DOJO и т. Д.) И используют REST/JSON для общения с веб-сервисами для получения и отображения данных на клиенте. боковая сторона. В этом сценарии у вас может быть полнофункциональное приложение на стороне клиента и еще одно полнофункциональное приложение на вашем бэкэнде... каждое со своими собственными реализациями логических уровней, которые я описал выше.
Варианты широко открыты.
Мой взгляд на вещи:
3-х уровневый не совпадает с MVP/MVC.
Многие люди интерпретируют "Модель" как очень широкую концепцию, которая может содержать много поведения (включая предметную логику). Я не. Модель - это то, что вид должен визуализировать сам. Иногда это может иметь поведение, но, опять же, только для поведения, связанного с отображением представления.
С MVP у вас есть отображение 1-1 между View и Presenter. Хотя концептуально вы могли бы иметь больше в действительности, это, вероятно, не будет таким образом. Докладчик занимается только посредничеством между другими слоями и видом.
С MVC существует, по всей вероятности, более 1 вида, с которым имеет дело контроллер, поскольку он связан с потоком.
Таким образом, MVC/MVP могут использоваться вместе и связаны с внешним интерфейсом и являются частью n-уровневой архитектуры.
Надеюсь, что это имеет смысл.
Вы увидите в таких ответах, как это Что такое MVP и MVC и в чем разница? Именно MVC и MVP обращаются к структуре кода, связанной с UI. Они решают такие вопросы, как:
- Какой компонент понимает действия пользователя?
- Какой компонент решает, какой вид представить дальше?
- Какая связь между View и Model?
Ни MVC, ни MVP не углубляются в детали того, что находится внутри (или ниже) модели. В некоторых системах Модель сравнительно проста, просто тонкий слой поверх базы данных, в других системах там очень много логики, например, интеграция с корпоративными системами, такими как SAP и CIC.
В своем традиционном значении трехуровневая архитектура (или, в более общем случае, n-уровневая архитектура) помещает дополнительную модель в модель.
В этой статье Википедии рассматриваются архитектуры n-уровня MVC. Я думаю, что разумно заменить MVP на MVC в этой статье.
Что касается архитектуры вашего приложения: мое восприятие состоит в том, что современные приложения имеют тенденцию иметь богатый пользовательский интерфейс, представленный в браузере, используя простые службы REST, предоставляемые моделью на каком-либо сервере, а затем некоторые произвольно сложные вещи в модели. Я думаю, вы можете увидеть это как n-уровневую архитектуру. Интересно то, что когда вы структурируете свой Javascript (JQuery, Dojo или любой другой) в браузере, вы обнаруживаете, что выходят шаблоны проектирования, и шаблон MVC на самом деле может появляться только на уровне представления.