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

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

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

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

Представления MVC и контроллеры вместе с View Models -are- Presentation Layer

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

Ответы

Ответ 1

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

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

  • Project.Core
    Реализации бизнес-логики/сервисов, сущности, интерфейсы, которые должны быть реализованы другими проектами (например, "IRepository", "IAuthenticationService",...)
  • Project.Data​​STRONG >
    Соединение с БД - в моем случае здесь находятся хранилища NHibernate и сущности-сопоставления. Реализует интерфейсы данных 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

Ответ 2

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

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

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

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

Ответ 3

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

Я знаком с несколькими шаблонами представления: MVP (Model, View, Presenter, common in windows forms/asp.net), MVC (Model, View, Controller) и MVVM (модель, представление, модель просмотра, обычно используется в WPF/Silverlight).

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

Выше ссылка должна ответить на некоторые (если не все) ваши вопросы.

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

Ответ 4

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

Если вы создаете новое приложение MVC, вы автоматически получите папку "Контроллеры, модели и виды".

Ваши контроллеры действуют как ваш бизнес-уровень
Модели - это Data Access/Service layer
и Views - это слой презентации.

Подробнее см. http://www.asp.net/mvc.