Какой подход лучше в ASP.net MVC?

Question

Первый Аппрох

   /\
  /  \
V/    \ C <=WCF=> {Business Layer (with business logic) <=> ORM <=> Database}
/      \
--------
    M

Второй подход

   /\
  /  \
V/    \ M <=WCF=> {Business Layer (with business logic) <=> ORM <=> Database}
/      \
--------
    C

Основная разница: - При первом подходе бизнес-объект будет иметь 2 версии. Один загружен со свойствами внутри бизнес-уровня, а другой - тупой версией с несколькими Просмотр определенных свойств, которые будут заполнены Контроллером. В то время как во втором appraoch, будет один класс со всеми свойствами. - Первый подход кажется немного более изолированным от уровня представления

В обоих случаях контроллер будет отправной точкой. Что касается мнений, которые я получил от разных людей, то оба они являются допустимыми подходами, и их можно переключать в соответствии с предпочтениями разработчика.
Пожалуйста, поделитесь мыслями.

Answer 1

Мы используем следующий подход в приложениях asp.net mvc:

• ViewModels - плоские объекты, которые собирают информацию для визуализации представления
• Контроллеры - сборка ViewModels из бизнес-объектов (которые имеют внутри себя логику или генерируются ORM)
• Модель - бизнес-объекты, которые недоступны для просмотра

View <- ViewModel <- Controller <-BusinessObject <- Db </p>

Подробнее об этом подходе можно узнать из Профессиональных шаблонов проектирования ASP.NET

Answer 2

Первый.ViewModels (как вы называете «M» в вашей триаде) не должны ничего знать в представлении или на вашем бизнес-уровне.

Настоящее определение MVC:

• Модель: бизнесслой, веб-сервис или что-то еще.
• Вид: UI
• Контроллер: склейка между моделью и представлением.

Microsoft добавила ViewModel, чтобы сделать разделение более четким,Для начала, представление не должно зависеть от моделей вашего домена.И в нем не должно быть логики.

Я перечислил основные причины использования моделей представлений здесь: http://blog.gauffin.org/2011/07/three-reasons-to-why-you-should-use-view-models/

Answer 3

imho Бизнес-логика принадлежит моделям. Контроллеры не должны знать или заботиться о том, почему вы хотите, чтобы что-то отображалось в ваших представлениях.

На самом деле, я думаю, что дело здесь в том, что лучше для работы, а не в абсолютном «лучшем».