我是依赖注入的新手，有一个问题/需要指导。
我有一个使用存储库模式进行数据访问的应用程序。我使用 StructureMap 来获取正确的存储库，并且一切正常。
我已经将我的模型（包括存储库逻辑）分解为自己的程序集并添加了一个服务层。为了 DI 的利益，服务层类在其构造函数中采用 IRepository。这对我来说似乎是错误的，因为现在我的模型的所有消费者都需要了解存储库（至少配置他们的 DI 以知道要使用哪个）。我觉得这已经进入了模型的核心。
这听起来有什么问题？
【问题讨论】：
标签： c# dependency-injection structuremap
为使用依赖注入而编写的应用程序通常配置一个容器实例，其中所有接口/实现类型映射都已在应用程序的初始化阶段注册。这将包括在应用程序中注册存储库、服务和服务的任何消费者。
通过容器解析服务的消费者，消费者只需要指出他们对服务的依赖，而不是服务可能需要的任何依赖。因此，服务的消费者不会耦合到它的依赖项（例如您的存储库）。这是通过容器进行依赖注入而不是手动进行依赖注入的好处。
如果您正在设计以可重用库的形式供其他应用程序使用的服务，那么您的选择将根据您希望提供的灵活性级别而有所不同。
如果您假设您的库的所有客户端都将使用依赖注入，那么您将需要提供适当数量的文档，说明哪些类型需要在其容器中注册。
如果您假设所有客户端都将使用特定容器（例如 StructureMap），那么您可以通过提供封装了客户端所有特定注册需求的注册表来简化注册要求。
如果您希望不使用自己的依赖注入容器的客户端使用您的库，那么您可以提供一个返回服务的静态工厂。根据复杂程度，这种情况可能不需要使用容器（例如，如果您的服务仅由几个对象组成）。如果您的库由大量需要组合的组件组成，那么您可能有工厂通过它们自己共享的内部基础架构初始化需求来解析服务。
【讨论】：
我理解你的困境，Dan，我也花了很多时间在脑海中纠结这个问题。我相信我决定采用的方法是封装所有关注点并且仍然具有易于维护的松散耦合对象的最佳方法之一。
我专门写了这篇关于 NHiberante 的博文，但如果您查看实施中的存储库模式，您可以轻松更改 NH 特定代码以使用您的后备存储。
Creating a common generic and extensible NHiberate Repository
【讨论】：