依赖注入(DI)“友好”库

Question

依赖注入(DI)“友好”库

我正在考虑C#库的设计，它将具有几种不同的高级功能。当然，这些高级函数将使用实心类设计原则越多越好。因此，可能会有供消费者定期直接使用的类，以及那些更常见的“最终用户”类的依赖关系的“支持类”。

问题是，设计库的最佳方法是：

• DI不可知论-虽然添加基本的“支持”一两个常用的DI库(结构地图、尼尼微等)似乎是合理的，但我希望消费者能够使用任何DI框架的库。
• 不可用的-如果库的使用者没有使用DI，那么库仍然应该尽可能容易使用，从而减少用户创建所有这些“不重要”的依赖关系所需的工作量，这仅仅是为了获得他们想要使用的“真实”类。

我目前的想法是为常见的DI库提供一些“DI注册模块”(例如，一个StructurereMap注册表，一个Ninject模块)，以及一个非DI并包含到这几个工厂的耦合的Set或Factory类。

思想？

Answer 1

编辑2015：时间已经过去了，我现在意识到这整件事是一个巨大的错误。IoC容器非常糟糕，DI是处理副作用的非常糟糕的方法。实际上，这里的所有答案(以及问题本身)都是要避免的。只需注意副作用，将它们从纯代码中分离出来，其他一切要么就会就位，要么就会变得无关紧要和不必要的复杂性。原答覆如下：我不得不面对同样的决定SolrNet..我一开始的目标是对DI友好和容器无关，但是随着我添加了越来越多的内部组件，内部工厂很快变得无法管理，由此产生的库变得不灵活。最后我写了我自己的非常简单的嵌入式IoC容器同时也提供了一个温莎设施和一个尼尼姆模块..将库与其他容器集成只是一个正确连接组件的问题，所以我可以轻松地将它与Autofac、Unitity、StructurereMap等集成在一起。缺点是我失去了new提高服务水平。我还依赖于CommonServiceLocator我本可以避免的(我可能会在将来重构它)，以使嵌入式容器更易于实现。这里有更多的细节。博客帖子.质检似乎依赖类似的东西。它有一个IObjectBuilder接口，它实际上是CommonServiceLocator的IServiceLocator，有几个方法，然后它为每个容器实现这一点，即NInjectObjectBuilder和一个常规的模块/设施，即质数传递模..然后它依赖于IObjectBuilder实例化它需要的东西。当然，这是一种有效的方法，但就我个人而言，我不太喜欢它，因为它实际上是在容器周围传递太多，使用它作为服务定位器。单轨实施器它自己的容器同时，它也实现了好的IServiceProvider..此容器在整个框架中使用，通过公开知名服务的接口。..要获得混凝土容器，它有一个内置服务提供者定位器..这个温莎设施将此服务提供者定位器指向Windsor，使其成为所选的服务提供者。底线：没有完美的解决方案。与任何设计决策一样，这个问题需要在灵活性、可维护性和便利性之间取得平衡。