ASP.net MVC: Является ли этот шаблон разумным или концептуально неправильным?

Question

Мои контроллеры передают запрос в соответствующую службу. Затем Служба совершает звонки в различные репозитории. Хранилища используют объекты Linq для Sql исключительно для DataAccess, а затем отображают и возвращают в качестве объектов домена. Затем служба решает, что будет представлять контроллер, и заменяет объекты DO с представлением, которые возвращаются контроллеру для отображения в представлении.

SO У меня есть услуги-Хранилища-домен Objects- Презентация объектов

Я спрашиваю, потому что кажется, что у меня есть много объектов, некоторые из них не делает ничего, кроме передачи данных. Является ли это разумным сценарием или я не следую правильному шаблону MVC?

Answer 1

Да, у вас есть правильная идея. Это может быть много классов и интерфейсов (даже не считая модульных тестов и макетов/тестовых классов), но если у вас есть приложение с приличным размером, вы клевете, чтобы иметь много в любом случае. Но для начала, это большая работа для небольшого первоначального выигрыша.

Я видел проекты, пропускающие некоторые из реализаций сервисов для базовых сервисов, которые просто передаются в репозиторий без какой-либо добавленной стоимости службой. Они идут прямо в хранилище от контроллера и, похоже, не теряют много.

Существуют и другие способы облегчения бремени некоторых классов с помощью инструментов, где это возможно. Например, проекты, такие как AutoMapper, могут помочь упорядочить объект вашего домена, чтобы просмотреть сопоставления моделей.

Answer 2

Если ваше приложение достаточно большое, ваш шаблон имеет смысл. В противном случае, я чувствую запах overengineering ...

Спросите себя: что, если этот слой не существует, и вы узнаете, правда это или нет.

Answer 3

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

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

Одна проблема, с которой я столкнулся, заключалась в том, что вы не можете сериализовать объекты Linq2Sql и поэтому иногда приходилось переводить эти объекты в объекты представления.