Interface 依赖注入&；使用接口？

我注意到许多开发人员为每个将要使用DI框架注入的类定义了一个接口。为每个类定义接口的优点是什么？

如果您不按照接口进行设计，那么当需要重构代码和/或添加增强功能时，您将受到阻碍。在设计接口时，使用DI框架并不是真正的问题。DI为您提供的是后期绑定和更好的编写单元测试的能力。

让您的应用程序组件（包含应用程序逻辑的类）实现接口非常重要，因为这促进了以下概念：

程序是一个接口，而不是一个实现

这实际上是一个问题。这样做允许您替换、拦截或修饰依赖项，而无需更改此类依赖项的使用者

然而，在许多情况下，当类和接口之间存在几乎一对一的映射时，开发人员将违反这些原则。几乎可以肯定违反的原则之一是，因为当每个类都有自己的接口时，就不可能使用横切关注点扩展（修饰）一组类（没有动态代理生成技巧）

在我编写的系统中，我定义了两个通用接口，它们覆盖了业务层的大部分代码。它们被称为

ICommandHandler

和

IQueryHandler

：

公共接口ICommandHandler
{
无效句柄（TCommand命令）；
}
公共接口IQueryHandler，其中TQuery:IQuery
{
TResult句柄（TQuery查询）；
}

除了不必定义许多接口的好的副作用之外，这允许极大的灵活性和测试的简易性。你可以阅读更多关于它的信息

根据我编写的系统，我还可能使用以下接口：

• IValidator

  用于验证消息

• ISecurityValidator

  用于对消息应用安全限制

• IRepository

  ，存储库模式

• IAuthorizationFilter

  用于对

  IQueryable

  查询应用授权/安全筛选

---

根据我编写的系统，大约80%到98%的组件实现了我定义的其中一个通用接口。这使得将横切关注点应用于所谓的琐碎关注点变得微不足道。

为什么要关闭？花点时间留下评论怎么样？-1查看常见问题解答要点“我可以在这里问什么问题？”和“我不应该在这里问什么问题”。它们是列表中的前两个。您的问题是有效且有趣的问题，但它有点模糊且不太具体（例如，没有代码示例），这就是为什么人们否决了它并投票将其关闭。相关：