Ну, я полагаю, ваш вопрос в том, как спроектировать "слои" в приложении MVC.
Взгляните на эту простую архитектуру, я использую ее для своих приложений MVC, и она кажется чистой и эффективной.
проект в решении - бизнес-модель - простая библиотека классов, полная классов POCO, представляющих бизнес-область. Вы можете использовать аннотацию данных здесь, классы метаданных для логики валидации и т. Д.
проект - EF-репозитории - еще одна простая библиотека классов; здесь определен контекст (сначала неплохой код EF, но сначала вы можете использовать базу данных EF или сначала модель - вам просто нужно добавить шаблон POCO T4 в библиотеку классов бизнес-модели, ничего страшного) и набор классов - хранилища
проект - я обычно называю его «ServiceLayer» или около того (я открыт для предложения лучшего имени :) - он содержит только интерфейсы, для репозиториев и других сервисов (реализованных в отдельных проектах), которые будут мои MVC ( или применение любой другой технологии); репозитории из 2.project реализуют эти интерфейсы
проект - сайт MVC. Он использует внедрение зависимостей (сборка в DependencyResolver, и я люблю использовать контейнер Ninject) для отображения репозиториев (и других сервисов); Тогда вы можете использовать инжектор конструктора в контроллеры или какой-нибудь «ленивый» подход (см. Ниже)
Это выглядит примерно так:
Тощий контроллер:
public class SomethingController : BaseController
{
public ActionResult DoSomething(SomeBusinessThing input)
{
if (ModelState.IsValid)
{
var result = CustomerRepository.DoSomeBusinessLogicAndPersistenceAndStuff(input);
return View(result); // you can use AutoMapper here, if you dont want to use business object as viewmodels
}
}
}
Мой "репозиторий" наследуется от моего BaseController:
public class BaseController : Controller
{
// ... other stuff used by all (or multiple) controllers
private ICustomerRepository _customerRepository;
protected ICustomerRepository CustomerRepository
{
get
{
if (_customerRepository== null)
_customerRepository= DependencyResolver.Current.GetService();
return _customerRepository;
}
}
}
Вы можете использовать этот «ленивый» DI, если ваш контроллер использует много сервисов, но только 1-2 на действие, поэтому было бы неэффективно вводить все из них с помощью конструктора. Кто-то может сказать, что вы «скрываете» зависимость таким образом, но если вы храните все это в одном месте - BaseController, это не страшно.
Что ж, внедрение репозитория - это действительно ваше дело. Приложение MVC даже не знает, что вы используете EF, оно знает только интерфейсы сервисов и не заботится о последующей реализации (которую вы можете переключить в любое время позже, если вам нужно!)
Заключение:
Контроллеры тонкие - без бизнес-логики
Модель FAT - и в этом случае репозитории инкапсулируют всю бизнес-логику (вы также можете использовать другие типы сервисов, например, некоторые калькуляторы для обработки и т. Д., Помните, MVC не заботится, знает только интерфейсы)
ViewModels являются входными данными для Views (и ViewModel может быть вашей бизнес-моделью напрямую или вы можете использовать AutoMapper для создания "чистых" ViewModels)