Unity: стандартное и условное разрешение - PullRequest
Новая
       8

Unity: стандартное и условное разрешение

2 голосов
/ 11 октября 2011

A. Простой вопрос.

У меня есть 3 экземпляра «Репозитория», который зависит от «Конфигурации». 

class Manager{ 
  public Manager(Configuration conf){
...

Стратегии разрешения для 3 экземпляров: 

container.RegisterType<Repository>("ForService1");
container.RegisterType<Repository>("ForService2");
container.RegisterType<Repository>("ForService3");

(три из-за того, что они имеют дополнительные параметры, которые не включены в выборку, параметры, которые всегда различаются)

и конфигурация по умолчанию 

container.RegisterType<Configuration>(new InjectionConstructor(new object[] { false, true }));

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

    <register type="Configuration" 
              name="**ForService2**">
      <constructor>
        <param name = "useOptimization1" value="True"/>
        <param name = "useOptimization2" value="True"/>
      </constructor>
    </register>

И вы хотите, чтобы в расширении не было тройной конфигурации, например: 

container.RegisterType<Configuration>("ForService1", new InjectionConstructor(new object[] { false, true }));
container.RegisterType<Configuration>("ForService1", new InjectionConstructor(new object[] { false, true }));
container.RegisterType<Configuration>("ForService2", new InjectionConstructor(new object[] { false, true }));

Возможно ли это? Как?

B. Сложный вопрос.

У меня такое ощущение, что инструмент IoC не о конфигурации. Попытка настроить инфраструктуру, выбросить конфигурационный файл IoC - это еще один антипаттерн. Или короче: «Данные о конфигурации не являются зависимостью». Я прав?

Давайте рассмотрим конфигурацию списков EntLib. Действительно, конфигурация приемника журнала EntLib является «поздним связыванием» или «способом конфигурации»? Во-первых, это «поздняя привязка» (так как мы указываем имя типа - какую сборку на loas и объект для создания), а также это «конфигурация» (у нас есть пользовательский раздел конфигурации). Я чувствую, что большинство последователей IoC выберут включенную «конфигурацию» контейнера, я прав? Но ребята из EntLib выбирают раздел конфигурации. Может быть, этот пользовательский раздел конфигурации для конфигурации прослушивателя журнала изменит конфигурацию контейнера, и как «конфигурация прослушивателя» должна быть связана с конфигурацией контейнера?

Ответы [ 2 ]

1 голос
/ 17 октября 2011

Я хочу подтвердить, что лучший способ - настроить контейнер из кода, и даже не только из кода, но и из мудрого кода.Типичным примером является конфигурация EntLib из «библиотеки лямбда-выражений конструкторов»:

http://msdn.microsoft.com/en-us/magazine/ee335709.aspx

yield return new TypeRegistration<Database>(
       () => new SqlDatabase(
           ConnectionString,
           Container.Resolved<IDataInstrumentationProvider>(Name)))
       {
           Name = Name,
           Lifetime = TypeRegistrationLifetime.Transient
       };

такие конструкции будут позже интерпретированы для построения конфигурации контейнера!

1 голос
/ 13 октября 2011

Ответ A

Используйте контейнер с поддержкой Convention over Configuration. Вы можете увидеть сравнительную таблицу здесь .

Ответ B

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

...