Какие соглашения / идиомы / шаблоны вы используете при настройке контейнеров IOC с использованием новых интерфейсов Fluent

Question

Я перебираю большой кусок кода в Castle Trunk, который включает в себя новый свободный интерфейс для настройки контейнера. Поскольку в проекте имеется огромный xml-файл windsorConfig, который не поддается обслуживанию, я подумал, что начну использовать эту новую функцию. Я знаю, что другие контейнеры (например, StructureMap 2.0) также содержат свободные интерфейсы для конфигурации контейнеров, поэтому этот вопрос не основан на Виндзоре.

Мой вопрос: какие условные обозначения / идиомы / шаблоны вы используете для конфигурации контейнера с использованием новых интерфейсов в стиле беглого стиля?

Моей первой мыслью было создание где-нибудь статического метода (например, ContainerConfig.Config), который бы загружал все соответствующие типы, которые приложение использует в контейнер. Меня беспокоит то, что в конечном итоге эта монолитная функция окажется почти такой же неуправляемой, как файл конфигурации xml (за вычетом налога на угловые скобки).

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

Чем больше я об этом думал, тем больше вопросов мне казалось. Что вы думаете об этом?

Answer 1

Более подробно рассмотрим StructureMap 2.5. Он предлагает несколько функций, позволяющих значительно сократить объем работы по загрузке контейнера IOC. Это предлагает соглашение по технике конфигурации (см. Записи блога ниже)

Смотрите следующие недавние записи в блоге Джереми Миллера (автора StructureMap)

Создайте свое собственное соглашение о автоматической регистрации с StructureMap

        // Example from the blog post above
        var container = new Container(registry =>
        {
            registry.Scan(x =>
            {
                x.TheCallingAssembly();
                x.With<DefaultConventionScanner>();
            });
        });

StructureMap 2.5.2 выпущен

Answer 2

У меня был проект, в котором мы использовали Unity, и я посмотрел видео о StructureMap, и мне с самого начала понравилась идея регистрации.

Итак, я создал следующий интерфейс:

/// <summary>
/// An interface which must be implemented to create a configurator class for the UnityContainer.
/// </summary>
public interface IUnityContainerConfigurator
{
    /// <summary>
    /// This method will be called to actually configure the container.
    /// </summary>
    /// <param name="destination">The container to configure.</param>
    void Configure(IUnityContainer destination);
}

И у сборок есть класс Configurator по умолчанию. Мы также обернули наш Unity IoC, используя статический класс, чтобы мы могли вызывать IoC.Resolve<T>, и я просто добавил следующие функции в эту оболочку:

    /// <summary>
    /// Configure the IoC
    /// </summary>
    public static class Configure
    {
        /// <summary>
        /// Configure the IoC using by calling the supplied configurator.
        /// </summary>
        /// <typeparam name="TConfigurator">The configurator to use</typeparam>
        public static void From<TConfigurator>() where TConfigurator : IUnityContainerConfigurator, new()
        {
            From(new TConfigurator());
        }
        /// <summary>
        /// Configure the IoC using by calling the supplied configurator.
        /// </summary>
        /// <param name="configurationInterface">The configurator instance to use</param>
        public static void From(IUnityContainerConfigurator configurationInterface)
        {
            configurationInterface.Configure(instance);
        }
        // other configuration.
    }

Так что в форме инициализации я либо просто позвонил бы программе или веб-сайту:

IoC.Configure.From<BLL.DefaultMapping>();

В BLL есть такой класс:

public class DefaultMapping:IUnityContainerConfigurator
{
    public void Configure(IUnityContainer destination)
    {
        destionation.RegisterType<IRepository, SQLRepository>();
        // and more..
    }
}

Единственным недостатком является то, что все ваши слои связаны с выбранным контейнером IoC.

Обновление . После этого ответа я разместил в своем блоге статью, содержащую Оболочка Unity .

Answer 3

Сложные вопросы [и я не эксперт по IoC], но имейте в виду, что любая & монолитная статическая функция " не должно быть почти таким страшным, как файл конфигурации. Вы можете определить свои собственные соглашения для вещей, и попытаться абстрагировать вещи вниз. Я использую Ninject, но я думаю, что для Виндзора это будет связано с созданием коротких маленьких функций с использованием таких вещей, как Register со стратегией AllTypesOf:

kernel.Register(AllTypesOf<ISomethingProvider>.
    FromAssembly(Assembly.Load("SomeAssembly")));

Не знаю, как внутренние иерархии экспортируют свою собственную конфигурацию по умолчанию. Это кажется немного страшным и перевернутым.

Answer 4

Вы можете попробовать изучить структуру Ninject. Очень простой, свободный интерфейс и молниеносный;) Нет конфигурации XML, и API довольно прост. Настоятельно рекомендуется

Ninject