Как использовать SimpleInjector в многопроектном решении без создания циклических ссылок

Я запускаю многопроектное решение, которое будет иметь более одной точки входа, например, службу Windows, веб-сайты ASP.NET, контроллеры WebApi и т. д. Я остановился на SimpleInjector, так как он очень быстрый и мне не нужны какие-либо дополнительные Особенности.

Насколько я понимаю, SimpleInjector должен быть централизованно настроен при запуске. Начиная со следующего базового примера набора проектов

  • NS.Контроллеры
  • NS.Core.Data
  • NS.Core.Data.Model
  • НС.Веб
  • NS.WindowsService (предположим, что это не всегда будет работать)

С несколькими точками входа, куда должна идти начальная загрузка SimpleInjector и может/должна ли она обрабатываться централизованно (в этом случае процесс конфигурации должен будет ссылаться на все проекты, чтобы иметь возможность настроить все классы решений)?

Должен ли я иметь глобальный экземпляр (например, NS.Global.Container), который не ссылается ни на один из других проектов, и каждая точка входа отвечает за добавление собственных требований к экземпляру при запуске (изящно обрабатывая повторяющиеся регистрации, такие как NS.Core.Model)?

Должен ли я использовать событие ResolveUnregisteredType для обработки регистраций по запросу?

Мне просто не хватает каких-то школьных знаний?

ОБНОВЛЕНО:

Ссылки, предоставленные Стивеном в комментариях ниже, дают исчерпывающие ответы на этот вопрос.

Где найти модули Ninject в многоуровневом приложение уровня

Как инициализировать Ninject в части проекта класса сайта mvc


dependency-injection c# simple-injector inversion-of-control
person qujck    schedule 27.11.2012    source источник
comment
Вы можете загрузить контейнер централизованно, но лично я этого не сделал бы. Лучше для каждой точки входа настроить свой контейнер. Это не означает, что такие элементы, как ваши репозитории, не будут созданы в одном месте. Для этого может быть удобно использовать что-то вроде установщика Windsor. Вероятность того, что все ваши точки входа используют одни и те же элементы, зарегистрированные в контейнере, кажется маловероятной, и даже если они есть сейчас, их может не быть в будущем.   -  person Jack Hughes    schedule 27.11.2012
comment
Связанный: stackoverflow.com/questions/11985452/   -  person Steven    schedule 27.11.2012
comment
Связанный: заголовок stackoverflow.com/questions/13327940/   -  person Steven    schedule 27.11.2012

Ответы (2)


arrow_upward
5
arrow_downward

Каждая точка входа должна иметь свой контейнер начальной загрузки.

NS.Web должен иметь его, так как это веб-сайт (я предполагаю здесь). NS.WindowsService должен иметь один, так как это .exe (сервис).

Другие проекты выглядят как библиотеки классов, поэтому у них не будет загрузочного контейнера.

Теоретически да, вы можете определить контейнер частичной начальной загрузки в каждой библиотеке классов, который затем можно использовать в основном контейнере начальной загрузки (в веб-проектах/сервисных проектах), чтобы упростить жизнь. В частичном контейнере вы затем выполните начальную загрузку компонентов этой библиотеки классов.

person Maarten    schedule 27.11.2012
comment
Корень композиции – это термин, который обычно используется для загрузочный контейнер должен идти. - person Lukazoid; 11.12.2012

arrow_upward
8
arrow_downward

Почему бы не использовать интерфейс IPackage? Вы можете создавать пакеты в каждом модуле, а затем в каждой точке входа просто вызывать container.RegisterPackages();. Например, вся конфигурация для NS.Core.Data будет находиться в NS.Core.Data.dll и так далее. Затем его можно будет использовать как в NS.Web, так и в NS.WindowsService. В NS.Web просто настройте типы, которые ему указаны, а затем вызовите container.RegisterPackages(); и так далее. Ваш пакет NS.Core.Data может выглядеть так:

public class CoreDataPackage : IPackage {
    public void RegisterServices(Container container) {
        container.Register<ISomeService,SomeImplementation>();
        // etc...
    }
}
person amiry jd    schedule 27.11.2012