如何确定哪些类应该通过IOC容器构建，哪些不应该。我曾经在两种极端的项目上工作过，似乎只有在类指定特定技术（如日志记录或数据访问）时才应该使用接口？
人们是通过什么来区分这两者的呢？
2个回答
3
我不会画任何线条 - 越多越好。
发生的事情是，您将API拆分为小单元的能力越强，就越接近单一职责原则，因为隐藏在接口后面的所有内容都倾向于只做一件事，并且做得很好。
通过将接口注入到实现中，实现新接口并将其注入到其他类型中，等等，您最终将获得一个非常灵活的结构，在该结构中，您可以在几乎任何级别上变化实现细节，每个协作者本身都非常简单。
通过良好的DI容器和一些明智的约定，DI容器将自动为您处理大部分连接工作，因此配置不必过于复杂。
- Mark Seemann
11
坦白地说，很难相信这样的建议是认真的。它完全违背了Martin Fowler关于DI的原始文章的意图。此外，类的实现已经“隐藏在接口后面”：即类本身的公共接口！我的意思是，不需要为此使用分离的接口。（或者你是指“接口”的一般含义吗？）在大多数情况下，您根本不需要通过配置来“变化实现细节”-默认情况下这样做是过度设计，并且与DI的真正精神相矛盾。 - Rogério
@Rogerio：这个建议是认真的，我多年来一直非常成功地使用这个原则。虽然我尊重Fowler，但我们不必把他的每个字都当作圣经。做一个网络搜索，了解一下.NET社区对Fowler和Uncle Bob在DI方面的观点的看法。也许你会改变主意。 - Mark Seemann
如果您不使用 DI，那么如何实现低耦合？（请注意，我不是在询问使用 DI 容器，而是简单的 DI 构建块，例如构造函数注入。） - Mark Seemann
如果你不重视我的意见，那么为什么要和我讨论这个问题呢？ - Mark Seemann
我只是说我更重视知名作者的意见。我不认为你已经进入“知名”类别，但我确实重视你的意见，只是没有那么多：^} - Rogério
显示剩余6条评论
1
DI容器（假设使用了一个）要实例化的类应该是那些实现了分离接口的类，并且需要根据执行环境在运行时进行选择。
然后你可能会问：哪些类应该实现分离接口，哪些不应该呢？ 基本上有两个原因来创建一个新的独立接口：
- 你需要打破系统中两个部分之间的依赖关系（仅仅因为你可以而这样做是不可取的）。
- 你将拥有多个独立的实现（请记住，通过重构通常很容易引入一个单独的接口，所以应避免“如果”的思考）。
参考文献：http://martinfowler.com/articles/injection.html#SeparatingConfigurationFromUse
- Rogério
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接