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

Question

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

ТАК У меня есть Сервисы-Репозитории-Доменные объекты- Презентационные объекты

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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