design-patterns - 我应该在 IoC 上走多远？

Question

我刚刚在一个非常小的项目中使用了 IoC，我只需要测试一个对象。我现在开始将它实现到一个更大的现有项目中，但我不确定。

假设我有两个业务对象 Student和 Teacher两者都有一个名为 IUnitOfWork 的接口(interface)的构造函数注入(inject)它的具体实例为 SQLUnitOfWork或 InMemoryUnitOfWork .

所以如果我使用这个库，我可以不用担心使用 IoC 来构造我的对象，但是当我想在另一个中使用一个时会发生什么？所以说我懒加载属性 Student.Teacher并且需要获得一个新的Teacher对象，我该怎么做？

使用 IoC 容器来实现这一点似乎有些不对劲，但也没有具体的对象。在使用的每个对象上使用 IoC 似乎有些过分。

Answer 1

我通常避免在域层中使用 IoC - 您只想尝试在应用层访问内核(是的，您可能会经常访问内核)。

对于我的项目，我所有的业务对象通常都是 POCO，除了框架之外几乎没有依赖。

服务层往往有很多依赖关系，但并不经常直接访问内核。

你是否能做到这一点将取决于你对 ORM 等的选择，当然还有项目的现有架构。

如果您的业务对象具有需要解决的依赖关系，那么您将需要使用内核来解决它们，或者重构您的项目以删除依赖关系。