Блог

У меня есть ASP.NET Приложение MVC 1, использующее NHibernate и Castle Windsor для IoC. В контроллеры внедрены классы служб, и эти классы служб обрабатывают всю логику и действия, требуемые приложением. В классы служб внедрены репозитории. Каждый репозиторий обрабатывает один объект. Объекты отображаются в таблицу базы данных через NH. Я пытался сохранить однозначную связь между службами и контроллерами, но некоторые службы используются более чем в одном контроллере.

Проблема в том, что некоторые сервисы теперь имеют зависимости от 10-15 репозиториев. Например, в системе есть компонент выставления счетов, где определенные действия зависят от пользователей, заказчиков, заказов на выполнение работ, позиций заказов на выполнение работ, счетов-фактур, позиций строк накладных, налогов и т.д.

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

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

FWIW глава 6 моей книги содержит пример этого процесса, а также затрагивает некоторые умственные упражнения, которые вы можете выполнить, чтобы определить подходящие кластеры сервисов для группировки.

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

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

Еще одна вещь, которую вы, вероятно, создали в своем проекте, — это очень слабый уровень домена. Таким образом, ваши сущности — это в значительной степени просто объекты POCO, в то время как вся бизнес-логика содержится на вашем уровне обслуживания. Рассмотрите возможность переноса части или большей части этой логики в домен.