在阅读了 Mark Seemann 的关于依赖注入的书之后，我很高兴将我的团队从服务定位器反模式转移到一个更优雅的解决方案中，即我的 DI 永远不会出现在我们的代码中。虽然我们有一个接口将我们与我们选择的 DI 容器分离，但我总觉得我们过于依赖容器，同时 - 无法充分利用它，我看到很多充分的理由转向构造函数注入+抽象工厂模式。
我的问题与政策和程序有关：我们尝试遵循 T 的 SOLID 和相关原则。我们还将我们的课程标记为内部密封，除非他们有（明显的）理由不这样做。这在过去一直很好，因为它可以防止我们违反“代码到接口”的理念，因为跨程序集边界可见的所有内容都是接口，只能通过我们的容器获得。
在练习 Mark Seemann 的建议时，我突然想到我的课程需要公开，以便组合根能够将所需的组件组合在一起。在构建不应假定其引用代码将使用容器的共享库时尤其如此，尤其是它的容器风格。
在构建从一个程序集的对象映射到另一个程序集的映射器时，我也得出了这个结论。例如，我可能有一个 Models.Interfaces 层，业务层和存储库层使用它来来回传递数据。以前，我们只需在 Models.Interfaces 中创建一个实现合同的程序集，当 Business 和 Repository 需要一个新的 Model.Interface 实例时，它们都会使用服务定位器。如果没有服务定位器，我唯一的选择似乎是要么删除模型接口，要么在同一个项目中实现我的 Model.Interfaces，从而允许业务/存储库根据需要新建实例。
除了性能之外，我想知道在 Model.Interfaces 项目中拥有公共模型实现是否是一种设计味道，我想知道内部密封类是否可以与这种 DI 方法和谐相处，以及我是否错过了当涉及到接口编码和使用构造函数注入+抽象工厂DI模式时。