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

Question

我使用Castle Windsor，但我想这适用于所有DI容器......

我经常发现自己正在创建内部帮助程序类并将它们注入其他类。 （实际上Windsor不支持内部ctrs所以我通常最终将帮助程序类公开，这是我的第一个＆＃34;代码气味＆＃34;）。

辅助类可能有许多自己的依赖项，已经在Windsor中注册了类型，所以对我来说也是有意义的（也是我）用Windsor注册帮助器类，所以我可以将它注入到需要的类中它。 E.g。

public MyService : IService
{
    public MyService(MyHelper helper, other dependencies...)
    {
    }
}

在阅读了几篇文章后，我开始怀疑这是否是＆＃34;滥用＆＃34;温莎，或者只是一般糟糕的代码设计。如果是这样的话，我应该如何处理帮助类？

Answer 1

  

我经常发现自己正在创建内部帮助程序类并将它们注入其他类。

这是一种常见的重构技术，名为Facade Services：

  

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

关于内部课程的问题：

  

将帮助程序类公开，这是我的第一个“代码味道”）。

完全没有。公共课没有什么臭。如果您遵循“程序到接口”规则，那么如果实现是公共的，则没有问题。这简化了测试，因为单元测试将直接依赖于类。

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

Answer 2

  对我来说，给Windsor注册帮助类是有道理的（对我而言）   所以我可以把它注入需要它的类

发现：）

  

daxim是一种技术，其中一个对象提供   另一个对象的依赖关系。

如果依赖项是接口或类（或字符串或int ...）没有区别 - 它仍然是“依赖项”。帮助器或实用程序类是非常常见的辅助工具，但您可能会发现它对Dependency injection很有用，例如，这意味着我们可以program to an interface，或者将一个实现替换为另一个实现，而不会影响依赖它们的服务。