Question

我们使用Ioc容器来解析项目中的大多数对象，但似乎在任何地方使用它都是不合适的。在运行时，用户位于单个公司Id的上下文中，我似乎应该在构造函数（例如，存储库或工作单元）中传递该公司Id。我们可以在运行时使用公司Id的参数覆盖，但使用

有任何好处

var uow = IocContainer.Resolve<IUnitOfWork>(new ParameterOverride("companyId", companyId))

而不是

var uow = new UnitOfWork(companyId)

好的，所以我理解我可能想要在一段时间内创建一个不同的IUnitOfWork实现，然后我可以轻松地用Ioc配置交换新的实现，但我不相信我会做到这一点。

Answer 1

不，有时候调用new正是你想要的。一个例子是方法调用或窄范围的本地对象。

模型对象通常不受IoC容器的控制。您使用从启动时IoC容器永远不知道的用户传递给您的数据为每个新会话或请求范围实例化一个。

更新：Honza Brestan关于逻辑单位的观点是现货。典型的Spring层布局是基于接口的：

view->controller->service->persistence

服务使用其他服务，模型对象和持久性来完成用例。

Answer 2

我发现IoC的最大优势不在于实现交换（人们在大多数项目中都不会这样做），而是迫使你将代码分成更清晰的逻辑单元，这通常意味着它是可单元测试的，可管理的并且更容易推理整体。

考虑到这一点，我建议根据项目的逻辑单元为自己决定“注入粒度”。它可能是5个较大的模块，也可能是数十个不同的小型连接器。同样如duffymo所提到的，new可能是你想要的本地/狭窄范围。