Question

：一种。简单的问题。

我有3个＆＃34; Repository＆＃34;这取决于＆＃34;配置＆＃34;。

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

解决3个实例的策略：

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

（三个因为它们有其他参数未包含在样本中，参数总是不同）

和＆＃34;默认＆＃34;构造

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配置文件 - 是另一个反模式。或者更短：＆＃34;配置信息数据不是依赖性＆＃34;。我是对的吗？

让我们观察EntLib的列表器配置。真的，是EntLib的日志监听器配置a＆＃34;后期绑定＆＃34;或者＆＃34;配置方式＆＃34;？首先，这是后期绑定＆＃34; （因为我们指出了类型名称 - 什么程序集到loas和要创建的对象），这也是＆＃34;配置＆＃34; （我们有自定义配置部分）。我觉得大多数IoC粉丝会选择容器启用＆＃34;配置＆＃34;我是对的吗？但是EntLib的人选择了配置部分。可能是日志监听器配置的这个自定义配置部分将改变容器的配置以及＆＃34;监听器配置＆＃34;应该与容器的配置有关？

Answer 1

回答A

使用支持Convention over Configuration的容器。您可以看到比较图表here。

回答B

正确，IoC不应该是配置。相反，prefer code as configuration，最好采用编码约定的形式。

Answer 2

我想确认最好的方法是从代码中配置容器，甚至不只是从代码中配置容器，而是从明智的扩展代码中配置容器。终极样本是来自“构造函数lambda表达式库”的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
       };

此类构造稍后将被解释为构建容器配置！

Unity：默认和条件解析

2 个答案: