Итак, у ваших контроллеров будет код, который переводит POCO из Entity Framework в отдельные объекты модели представления?
Если это так, то вы должны переместить этот код в отдельный класс и следовать одиночномупринцип ответственности.Находится ли этот класс в «слое обслуживания» или нет, зависит от вас.И используете ли вы AutoMapper или нет, зависит от вас.Но такого рода преобразователи данных не должны быть частью логики контроллера;контроллеры должны быть настолько тупыми, насколько это возможно.
Хорошо, теперь давайте проигнорируем проблему отображения данных и представим, что вы всегда можете использовать свои POCO непосредственно в качестве моделей просмотра.Тогда вы бы все еще хотели бы иметь сервисный уровень, потому что он будет транслироваться между
userService.GetByUserName("bob")
в вашем тупом контроллере и реализовывать это особым образом, возвращая
userRepository.Users.Single(u => u.UserName == "bob")
Собрав их вместе, ваш UserController в итоге получит зависимости IUserService и IUserDataMapper, а код будет очень тупым, как вам нужно:
public ActionResult ShowUserPage(string userName)
{
var user = userService.GetByUserName(userName);
var viewModel = userDataMapper.MakeViewModel(user);
return View(viewModel);
}
Теперь вы можете протестировать контроллер с заглушками дляобе зависимости, или заглушить IUserDataMapper, пока вы издеваетесь IUserService, или наоборот.Ваш контроллер имеет очень мало логики, и имеет только одну ось изменения .То же самое можно сказать и о классе пользовательских данных-мапперов и классе обслуживания пользователей.
Сегодня утром я читал статью, в которой вы могли бы найти некоторую информацию по этим архитектурным вопросам.Он несколько снисходительно называется « Основы разработки программного обеспечения, часть 2: Многоуровневая архитектура ».Вы, вероятно, не сможете переключиться с модели приложения базы данных на модель постоянного невежества, которую описывает и предлагает эта статья.Но это может указать вам правильное направление.