我是新来依赖注入并有一个问题/需要指导。ModelMap DI上的StructureMap DI
我有一个使用存储库模式进行数据访问的应用程序。我使用StructureMap来获取正确的存储库，并且一切正常。
我已经将我的模型（包括存储库逻辑）分解为它自己的程序集并添加了一个服务层。为了DI的利益，服务层类在其构造函数中接受一个IRepository。这对我来说似乎是错误的，因为现在我的模型的所有消费者都需要知道存储库（至少配置它们的DI以知道使用哪一个）。我觉得这是进入模型的胆量。
这听起来有什么问题吗？
写入使用依赖注入一个应用程序通常配置在所有的接口/实现类型映射已在应用程序的初始化阶段中被注册的单个容器实例。这将包括注册存储库，服务以及该应用程序中的所有服务使用者。
通过通过容器解决服务的消费者，消费者只需要在服务说明的依赖，没有任何依赖该服务可能需要。因此，该服务的使用者将不会与其依赖关系（例如您的存储库）耦合。这是通过容器进行依赖注入的好处，而不是手动依赖注入。
如果你正在设计服务，其他应用程序中可重用库的形式被消耗掉，然后你的选择将取决于灵活性要提供的水平而有所不同。
如果你假定你的库的所有客户端将使用依赖注入，则需要提供相关文件，适量什么类型需要被他们的容器内注册。
如果假定所有客户端将使用的特定容器（例如StructureMap），则可以缓解通过提供封装所有客户端的特定注册需求的注册的注册要求。
如果你希望允许不使用自己的依赖注入容器的客户端使用您的图书馆，你可以提供一个静态工厂返回的服务。根据复杂程度的不同，这种情况可能不需要使用容器（例如，如果您的服务仅由几个对象组成）。如果您的库由大量需要组成的组件组成，那么您可能会有工厂通过他们自己共享的内部基础架构初始化需求来解决这些服务。
我明白你的困境，丹，我也花了很多时间在脑海里摔跤。我相信我决定推进的方式是封装所有问题并仍然具有易于维护的松散耦合对象的最佳方法之一。
我专门写这个博客帖子大约NHiberante，但如果你看看存储库模式中实现，你可以很容易地改变NH特定的代码来使用你的备份存储。
Creating a common generic and extensible NHiberate Repository