依赖注入和内部帮助程序类

And*_*ens 4 c# dependency-injection castle-windsor

我使用Castle Windsor,但我猜这适用于所有DI容器......

我经常发现自己创建内部帮助程序类并将其注入其他类.(实际上Windsor不支持内部ctrs所以我通常最终将帮助程序类公开,这是我的第一个"代码味道").

助手类可能有一些已经在温莎注册的类型了自己的依赖,因此它是有道理的(对我来说)注册与温莎助手类也一样,这样我就可以把它注射到需要它的类.例如

public MyService : IService
{
    public MyService(MyHelper helper, other dependencies...)
    {
    }
}
Run Code Online (Sandbox Code Playgroud)

在阅读了几篇文章之后,我开始怀疑这是否"误用"温莎,或者只是一般糟糕的代码设计.如果是这样的话,我应该如何处理帮助类?

Ste*_*ven 7

我经常发现自己创建内部帮助程序类并将其注入其他类.

这是一种常见的重构技术,称为Facade Services:

Facade Service隐藏了新抽象背后的聚合行为.

至于你关于内部课程的问题:

使助手类公开,这是我的第一个"代码味道").

一点也不.公共课没有什么臭.如果您遵循"程序到接口"规则,那么如果实现是公共的,则没有问题.这简化了测试,因为单元测试将直接依赖于类.

长话故事,你没有误用DI或DI容器.如果您将行为封装在帮助程序类中,那么您正在做正确的事情.然而,困难的是要找出从业务角度来看,封装行为的最佳方式是什么.但在这样做的同时,它可能会引导您进入新的内部和新的业务概念.


小智 1

(对我来说)向 Windsor 注册辅助类也是有意义的,这样我就可以将它注入到需要它的类中

发现 :)

依赖注入是一种技术,其中一个对象提供另一个对象的依赖关系。

如果依赖项是一个接口或一个类(或一个字符串,或一个整数......),这没有什么区别 - 它仍然是一个“依赖项”。帮助程序或实用程序类是非常常见的辅助工具,但您可能会发现对接口进行编程很有用,例如,这意味着我们可以出于测试目的模拟它们,或者用一种实现替换另一种实现,而不会影响依赖于它们的服务。