ASP.NET MVC - предложения по макету решения

Я работаю с ASP.NET MVC уже пару месяцев и все еще не доволен макетом решения моего проекта. Я пытаюсь создать CMS для веб-сайта среднего размера, которая была бы максимально портативной и многоразовой, и в ее дизайне есть некоторые очевидные проблемы. Мне нужен совет относительно того, как мне структурировать свое решение с учетом разделения проблем. Я нашел здесь аналогичный вопрос, но на самом деле он не нацелен на некоторые из проблемы, с которыми я сталкиваюсь.

Прямо сейчас мое решение изложено следующим образом:

+Project.Controllers - All Controller classes
P+roject.Controllers.Tests

+Project.Core - Utility classes including repetitive tasks and some configuration handlers (this project needs to be better fleshed out)
+Project.Core.Tests

+Project.Models - Model classes, Entity Framework context, and Repository classes
+Project.Models.Tests

+Project.Web - All Views and Content

Одна важная вещь, которой мне сейчас не хватает, - это место, где можно закрепить свою бизнес-логику, и я чувствую, что ошибочно размещал бизнес-логику в своих классах репозитория, а также смешивал ее с действиями контроллера. Очевидно, я хорошо осведомлен об этой проблеме, я просто не уверен, где мне разместить свою бизнес-логику в этом макете решения. Нужно ли изменить структуру моего решения, или я могу безопасно сохранить эту бизнес-логику в моем проекте моделей? Кроме того, мне действительно не нравится, что мой контекст EF находится в классе Models, но я не знаю способа изолировать код уровня данных от классов сущностей, необходимых в моей модели.

Как все остальные выкладывают свои производственные решения ASP.NET MVC?


person Nathan Taylor    schedule 25.08.2009    source источник


Ответы (3)


Возможно, вы захотите проверить макет, который использует проект архитектуры S # arp, или луковая архитектура, используемая в Code Camp Server эталонное приложение MVC. В оба проекта вложили много усилий разные люди, чтобы получить хорошее разделение проблем в контексте asp.net MVC и дизайна, управляемого предметной областью.

person olle    schedule 25.08.2009
comment
Где бы я разместил свой контекст Entity Framework в архитектуре S # arp? - person Nathan Taylor; 25.08.2009
comment
Я не знаю фреймворка сущности, так что отнеситесь к этому с недоверием. S # arp arch использует nhibernate для доступа к данным. Что вы можете сделать, так это сделать так, чтобы репозиторий требовал контекста ef в своем конструкторе, а затем внедрил его с помощью контейнера инверсии управления. jeffreypalermo.com/blog/ содержит пример кода, как добавить механизм отложенной загрузки, сохраняющий контекст в HttpContext, однажды созданный для одного запроса. Хотя это и конкретный образец nhibernate, он не должен сильно отличаться в EF. - person olle; 25.08.2009

Лично я изучаю только MVC. Мой опыт исходит из ASP.NET WebForms, но я бы выбрал макет, предложенный в приведенной вами ссылке. Второй ответ:

  • Модели
  • Просмотры
  • Контроллер
  • Услуги
  • Тесты - по одному на каждый проект.
person Finglas    schedule 25.08.2009
comment
Нет, это были бы твои модели. Сервисы, также известные как веб-сервисы, будут использоваться моделью, поэтому я полагаю, вы можете сказать это в некотором роде. - person Finglas; 25.08.2009

Я бы взял EF Context и Repositories из Models на уровень доступа к данным Project.Data и поместил ваши бизнес-объекты в Project.BusinessLogic (?).

Это дает преимущество помещения двух сборок (Project.Data и Project.BusinessLogic) в другие приложения, которые вы можете создать в том же домене. Это означает, что у вашего следующего проекта есть очень полезная отправная точка.

Надеюсь, это поможет,

Дэн

person Daniel Elliott    schedule 25.08.2009
comment
Если я перенесу контекст EF в новый проект, мои классы сущностей переместятся вместе с ним, есть ли способ с этим бороться? - person Nathan Taylor; 25.08.2009
comment
Вы бы сослались на свой BusinessLogic в своей модели. - person Daniel Elliott; 25.08.2009