Уровень обслуживания MVC-обслуживание на контроллер или другой дизайн?


У меня есть ASP.NET проект MVC со слоем данных (NHibernate and Repository pattern), сервисным слоем и веб-слоем (MVC).

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

Есть ли лучший способ структурировать это?

3 4

3 ответа:

Дублирование обычно означаетрефакторинг : извлеките дублированную логику в it's on service, разбейте все (принцип единой ответственности), пока больше не будет дублирования.

Затем вы либо просто вводите несколько служб в свои контроллеры (как вы уже сделали для вашего домашнего контроллера), либо вы можете создавать классы, которые объединяют несколько служб (см. Также делегирование, фасад, декоратор шаблон и рефакторинг для агрегирования услуги ) и вводить их.

Нет серебряной пули, поэтому вы не получите "правильный" ответ здесь. Это зависит от вашего конкретного сценария.

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

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

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

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

В разделе "Программирование Microsoft ASP.NET MVC", Дино Эспозито рекомендует шаблон, который он называет "IPODD". У меня мало опыта работы с MVC, но эту главу стоит прочитать, если вы можете ее получить. Я бы сказал, что это дает Опытное понимание вашего вопроса.

Вы можете просмотреть объяснение книги о шаблоне iPODD здесь.