(Автоматически) Механизмы привязки инъекций зависимостей

Question

Два общих механизма для создания привязок внедрения зависимостей, например, через контейнер IOC, взят из конфигурации XML или блока императивного кода.В этих случаях пара ключ-значение является явной (т. Е. Ключ = запрошенный тип, значение = возвращаемый тип).

Тем не менее, существует третий «эвристический» подход, когда дается только контейнер приложения / IOC [IMyClass] и контейнер затем отражается над набором зависимостей сборки приложения, чтобы найти все именованные конкретные классы [MyClass].Иными словами, значения «возвращаемого типа» обнаруживаются, а не объявляются.

Я хотел бы знать, что это в два раза:

1. Какие контейнеры IOC (или другие инструменты позднего связывания)) разрешить эвристический подход?Есть ли у этого подхода более распространенное имя?
2. Существуют ли другие методы связывания, помимо перечисленных трех, которые используются на практике?

Answer 1

Это называется Конфигурация на основе конвенции или Автоматическая регистрация и поддерживается следующими контейнерами .NET DI:

• Castle Windsor
• StructureMap
• Autofac

Наиболее распространенные механизмы конфигурации, используемые для DI-контейнеров:

• XML
• Код как конфигурация
• Конфигурация на основе конвенции

Четвертый, но необычный, подход заключается в использовании атрибутов. Managed Extensibility Framework является наиболее ярким примером этого подхода, который более распространен в Java.

Answer 2

То, что вы называете «эвристическим» подходом, - это то, что я называю условностями. Большинство контейнеров IoC позволяют вам переопределить способ разрешения привязок, что означает, что вы можете ввести любое соглашение, которое вы хотите. Нет таких соглашений по умолчанию, о которых я знаю. Скорее, большинство контейнеров ничего не делают по умолчанию; ваша задача - рассказать им, как разрешать типы, либо через файл конфигурации, либо через код.

Пример пользовательского соглашения, которое я нахожу, довольно распространено, что экономит много объявлений: если запрошенный тип является типом интерфейса, начинающимся с «I» и заканчивающимся «Service», то попытайтесь создать и разрешить тип с помощью одно и то же имя, кроме "я". Это автоматически разрешит имена вроде IFooService до FooService. Кроме того, вы можете легко внедрить логику для выбора разных сервисов в разных контекстах и ​​управлять временем жизни экземпляров сервисов в общем месте.

Так как вы можете переопределить привязку большинства контейнеров IoC, вы можете также ввести другие способы поведения. Как правило, однако, есть два варианта:

1. Настройка во время выполнения (через файлы конфигурации, такие как файлы XML)
2. Настройка во время компиляции (либо через декларативный DSL-подобный API, либо через пользовательские соглашения или другую форму пользовательской логики)

Answer 3

Поскольку я немного использовал StructureMap , я бы знал, как сделать такую ​​вещь с этим контейнером: в основном это будет соглашение о пользовательской регистрации (от инициализации или реестра, перейдите вСканируем лямбда-блок и находим «конвенционный» метод).

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

Answer 4

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