ASP.NET MVC vs. nTier Разделение проблем

Question

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

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

Как эта архитектура способствует хорошему разделению проблем, когда эти два слоя смешиваются?

Answer 1

Существует разница между View Models и Domain Mod. Domain Models - это ваш домен приложения. Эти модели можно использовать везде, на любом уровне, и они обычно размещаются в отдельном совместном проекте. Ваши модели просмотра предназначены только для пользовательского интерфейса. Они зависят от ваших потребностей/структуры страницы. Предположим, вы хотите создать страницу управления пользователями, чем ваша модель представления может быть классом с 2 свойствами User и List<Role>, где User и Role - это модели домена.

И, наконец, ваши модели данных обычно являются объектами передачи данных. Модели Entity Framework обычно используются в качестве моделей данных и доменов одновременно.

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

Answer 2

Andrei M находится на месте. Я согласен с различием моделей View и моделей домена. Это может помочь думать о M в MVC как о модели для ваших взглядов, и эти «модели представлений» не должны знать, откуда они берут свои данные. В этом заключается разделение проблем. Контроллер будет предлагать обмены, необходимые между вашей моделью домена и вашими моделями просмотров, чтобы заполнить модели представления данными. Эти обмены данными, что брокеры-контроллеры часто достигаются с использованием другого уровня, такого как репозиторий, инфраструктура или уровень обслуживания ... но необязательно. В однопроектном решении ваша папка «Модели» может содержать модель домена, а затем у вас может быть отдельная папка «ViewModels». Контроллер будет получать данные через «Модель», а затем заполнять модель представления данными, полученными им от модели. Модель просмотра будет базовой моделью вашего строго типизированного представления. Можно задаться вопросом, почему разработчик может даже потрудиться с использованием модели представления, если между объектом домена и представлением существует простое взаимно однозначное сопоставление. Одним из примеров является то, что вам может потребоваться «сгладить» объект домена и его отношения. Другой пример может заключаться в том, что для страницы индекса или списка может потребоваться включить фильтр поиска; просматривать модели значительно упрощают размещение изменений в требованиях.

Answer 3

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

Мы должны принять во внимание, что, когда мы говорим о ASP.NET MVC, мы говорим о «User Interface» так, это пользовательский интерфейс рамки не является приложением один. В MVC проблемы разделены на три компонента: Model, View и Controller.

В многослойной или многоуровневой архитектуре проблемы в основном разделены слоями представления, приложения, бизнеса и данных, которые представляют собой архитектуру структуры приложения, а ASP.NET MVC принадлежит к слою Presentation.

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