Каков правильный уровень для настройки вашего контейнера IoC при использовании сервисного уровня?

Question

У меня среднее приложение asp.net MVC. Он использует сервисный уровень, который обрабатывает все использование репозитория, вызывает доменные сервисы и т. Д. Мои действия контроллера очень тонкие - они в основном вызывают класс сервиса, получают ответ и показывают, что они располагаются. Большинство компонентов основаны на интерфейсе с цифровым интерфейсом бедного человека. Приложение растет, нуждается в улучшенной поддержке тестирования и начинает вызывать контейнер IoC.

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

Думаю ли я об этом правильно или мне просто нужно это преодолеть?

Answer 1

У меня такая же ситуация, как и у вас, и я решаю ее следующим образом.

Общее правило, которое я использую, это то, что когда-либо имеет global.asax или что-то подобное, ему нужно выполнить код, который регистрирует IoCкомпоненты.Другими словами, вам нужно запустить его по одному для каждого другого процесса, который выполняется (т. Е. Веб-сайт находится в одном процессе, а служба - в другом).

В моем случае я делаю это один раз длявеб-сайт MVC global.asax и снова для сервера.В этом случае регистрация будет отличаться для службы и веб-сайта.

Кроме того, я делаю еще одну вещь.В связи с тем, что я повторно использую компоненты между приложением mvc и службой (то есть ведение журнала), у меня есть третий основной компонент, который регистрирует основные компоненты IoC для системы, и этот компонент вызывается при регистрации как на веб-сайте, так и в службах.Следовательно, все, что является общим для службы и веб-сайта, входит в базовую регистрацию, а затем все, что отличается, входит в специфическую регистрацию «интерфейса».

Надеюсь, что это поможет.

Answer 2

Вам просто нужно преодолеть это:)

Наличие вашего Composition Root в корне приложения не требует наличия большого количества DI-контейнера в web.config.Вы можете, если хотите, но это необязательно. не является обязательным при помещении корня композиции в корень приложения: вам нужно иметь некоторый код DI в Global.asax., но это не настоящая точка зрения.Фактический момент заключается в том, что вы (абстрактное «вы») хотите отложить объединение классов до последнего ответственного момента .Чем раньше вы объедините типы, тем меньше у вас гибкости.

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

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

Answer 3

Исходя из перспективы Java, я использую среду Spring для своего контейнера IoC.С этим контейнер действительно для всего приложения.Хотя у вас могут быть разные файлы конфигурации для разных слоев (файл конфигурации постоянства, файл конфигурации служб, файл конфигурации контроллера и т. Д.), Все объекты (бины в языке Java) входят в контейнер.

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