我更喜欢使用构造函数注入,并且经常会发现我需要在构造函数中注入大约5个或更多的对象.似乎太多了,也许这是一个设计问题,没有得到SRP的权利.但是我认为我的使用DI也是被指责的.
我正在寻找“最佳实践”或“经验法则”,一般来说,我似乎注入了一切,那不是在.Net框架中,是否超负荷？
为了让事情开始,这里是我注入的两个对象的例子,但不确定.
对象是真正的单身,如应用程序配置或那些小的util类,你注入它们？
他们似乎经常被注入,注入它们的唯一原因似乎是允许改变测试的价值,但是Ayende似乎以另一种方式解决了这个问题：http://ayende.com/Blog/archive/2008/07/07/Dealing-with-time-in-tests.aspx.
应该注入几乎所有对象中使用的日志记录等常用对象？
注入对象的其他原因,例如能够在稍后的时间替换模块(例如用于验证,UI或O / RM的交换机实现),以允许团队内部或跨团队的并行开发,并降低维护.
I prefer to use constructor injection
and have often observed that I need
about 5 or more objects to be injected
in the constructor.
正如您已经注意到的那样,拥有许多依赖关系可能是由于不遵守SRP而导致的.然而,您可以做的是将常见的依赖关系与逻辑分组成一个聚合服务,并将其注入消费者.还有马克·塞曼关于Aggregate Services的文章.
Objects that are true singletons like
application configuration or those
small util classes,do you inject
them?
我个人不是Ayende提出的方式的粉丝.这是Ambient Context,它是一种特定类型的service locator构造.这样做会隐藏依赖关系,因为类可以调用该静态类,而无需注入它.明确地注入它使得更加清晰,你需要单元测试时间.除此之外,它很难编写测试,例如MSTest框架,他们倾向于并行运行测试.没有任何对策,它使您的测试非常不可靠.一个更好的解决方案 – 对于DateTime.Now示例,是具有一个IClock接口,如建议here.可以看出,这个答案比Ayende方法高得多,这在同一个SO问题中显示.
Common objects such as logging,that
are used in almost every object,
should they be injected?
我将其注入到我的代码中,因为这样可以使依赖关系清晰.但是请注意,在我的代码中,我几乎不必注入一个记录器.想想你想要登录的每一行,并不是真正的失败(或者应该放在其他地方的交叉关切).当我没有想到的事情发生时,我通常会抛出异常.它允许我快速找到错误.或者换句话说：不要过滤,但是快速失败.请问你自己：“Do I log too much?”
我希望这有帮助.
