Как архитектура ASP .NET MVC вписывается в традиционную многоуровневую архитектуру

Question

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

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

В качестве ссылки, ниже, как я понимаю, пожалуйста, поделитесь своим мнением об этом

MVC Views и Controllers вместес моделями представления -are- Уровень представления

Модели MVC - могут быть - Уровень доступа к данным или бизнес-уровень или даже уровень обслуживания

Answer 1

Я вижу Asp.Net MVC part только как представление (или представление) части всего приложения.

Я тоже боролся с проблемой правильной структуризации приложения.
Следуя Луковой архитектуре , о которой я слышал здесь (и особенно изображение, найденное здесь ), мое решение выглядит следующим образом:

• Project.Core
  Реализации бизнес-логики / сервисов, сущности, интерфейсы, которые должны быть реализованы другими проектами (например, «IRepository», «IAuthenticationService», ...)
• Project.Data
  Соединение с БД - в моем случае сюда отправляются репозитории NHibernate и отображения сущностей. Реализует data -интерфейсы Project.Core
• Project.UI.Web
  Проект Asp.Net MVC («презентация») - объединяет все приложение.
  Имеет реализации для Интерфейсов в Project.Core и соединяет их (и те, что из Project.Data) с некоторой структурой DI, такой как Castle Windsor.

Project.UI.Web следует следующим соглашениям:

• его модели являются только (!) viewmodels
• просмотров потребляют их собственную модель представления (модель одного просмотра - один просмотр)
• контроллеры просто нужно проверить входные данные, преобразовать его в доменные объекты (в качестве бизнес-логики точно ничего не знает о моделях представления ) и делегирует реальную работу (бизнес-логику) бизнес-службам.

Резюме:
Если вы следуете этой модели, полезно сосредоточиться на Project.Core : , что является реальным приложением . Он не беспокоится о реальной сохранности данных и не заботится о том, как они представляются. Это просто "как это сделать". Но он устанавливает правила и контракты (интерфейсы), для которых другие проекты должны предоставлять реализации.

Надеюсь, это поможет вам с макетом приложения Asp.Net MVC!

Lg
warappa

Answer 2

Как уже говорили другие, это мало что меняет.Мои приложения обычно имеют такую ​​архитектуру:

• Уровень модели (модели домена и представления)
• Уровень репозитория (доступ к данным)
• Уровень обслуживания (иногда реализованный как WCF)услуги в зависимости от приложения / требований)
• Уровень MVC на стороне сервера (сам MVC Asp.net)
• MVVM на стороне клиента или MVC (через Knockout.js, Backbone.js или Spine.js)

На уровне MVC на стороне сервера мои методы контроллера очень легки.Обычно они вызывают метод объекта сервисного уровня, чтобы получить некоторые данные и передать их клиенту в виде данных Json.

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

Answer 3

Короче говоря: ничего особенного не меняется.

Я знаком только с несколькими шаблонами представления: MVP (модель, вид, презентатор, распространенный в формах windows / asp.net), MVC (модель, вид, контроллер) и MVVM (модель, вид, модель представления, обычно используется в WPF / Silverlight).

Ссылка: http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx

Над ссылкой следует ответить на некоторые (если не все) ваши вопросы.

Обычно я пишу приложения ASP.NET MVC путем включения по крайней мере гибрида уровня обслуживания / бизнеса для операций CRUD (поскольку доступ к данным не принадлежит ни к модели представления, ни к контроллеру и определенно не к представлению!).

Answer 4

Очень простое объяснение:

Если вы создадите новое приложение MVC, вы автоматически получите папку Controllers, Models and Views.

Ваши контроллеры действуют как ваш бизнес-уровень
Модели доступа к данным / сервисный уровень
и представления являются уровнем представления.

См. http://www.asp.net/mvc для подробного объяснения.