最好的做法是在域模型的边缘解析和注入具体类型,然后通过域下载这些类型？例如,让容器将具体类型注入Web应用程序中的MVC控制器构造函数或基于服务的应用程序中的服务端点？ 我对
我对容器对象图形连线的理解有点松懈.
是否适合在域中执行等效的Container.Resolve()？
DI实际上只是达到目的的手段：松耦合.这是一种通过将接口(或基类)注入消费者来实现松耦合的方法,这样您就可以彼此独立地改变它们.作为一般规则,通过注入混凝土类型没有任何好处.您无法将该类型与其他类型交换,因此DI的主要优势将丢失.
您可能会认为这意味着您只需从消费者中创建具体实例,但更好的选择是从这些类型中提取接口(然后注入它们).
而且：从域模型中提取容器永远不合适.这就是Service Locator anti-pattern.好莱坞原则也适用于此：
Don’t call the container; it’ll call you
(也就是说,即使是具体的类型,注入它也有一些辅助的好处.如果它是非密封的并且有一个或多个虚拟成员,你仍然可以覆盖它的一些行为,即使它被密封,你仍然得到如果你注入它来控制它的生命周期 – 例如你可以在多个消费者之间共享相同的实例.但是,这些好处纯粹是次要的,通常不是我们决定注入任何东西的主要原因.)
另一个问题(以及您似乎实际要问的问题)是注入服务是否适合将其传递给其他服务.不,不是,因为它会违反单一责任原则并导致Constructor Over-Injection.
最好将细粒度服务包含在更粗粒度的服务中.我将这些称为Aggregate Services或抽象外墙.虽然这些本身具有依赖性(如您提到的服务端点),但这些将是实现细节.从顶级消费者的角度来看,它们并不存在.
这不仅可以很好地解决构造函数中过多依赖项的问题,还可以帮助您在应用程序层之间实现更好的隔离.