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