关于c＃：Dependency Inject（DI）“友好”库

Dependency Inject (DI) “friendly” library

我正在考虑C库的设计，它将具有几个不同的高级功能。当然，这些高级功能将尽可能使用实体类设计原则来实现。因此，可能会有一些类专门供消费者定期直接使用，"支持类"是那些更常见的"最终用户"类的依赖项。

问题是，设计图书馆的最佳方法是什么？

DI不可知-尽管为一个或两个通用DI库(structuremap、ninject等)添加基本的"支持"似乎是合理的，但我希望用户能够将该库与任何DI框架一起使用。
不可DI使用-如果库的使用者不使用DI，那么库应该仍然尽可能容易使用，减少用户创建所有这些"不重要"依赖项所需的工作量，以获得他们想要使用的"真实"类。

我目前的想法是为公共DI库(例如，structuremap注册表、ninject模块)提供一些"DI注册模块"，以及一个非DI的集合类或工厂类，其中包含到这些少数工厂的耦合。

思想？

相关讨论

一旦您理解DI是关于模式和原则的，而不是技术的，这实际上很简单。

要以不可知DI容器的方式设计API，请遵循以下一般原则：

程序到接口，而不是实现

这个原则实际上是引用(从内存中)设计模式，但它应该始终是您的真正目标。DI只是实现这一目的的一种手段。

运用好莱坞原则

好莱坞的DI原则是：不要叫DI容器，它会叫你。

不要通过从代码中调用容器来直接请求依赖项。通过使用构造函数注入隐式地请求它。

使用构造函数注入

当需要依赖项时，通过构造函数静态地请求它：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class Service : IService
{
private readonly ISomeDependency dep;

public Service(ISomeDependency dep)
{
if (dep == null)
{
throw new ArgumentNullException("dep");
}

this.dep = dep;
}

public ISomeDependency Dependency
{
get { return this.dep; }
}
}

注意服务类如何保证其不变量。创建实例后，由于guard子句和readonly关键字的组合，依赖项保证可用。

如果需要短期对象，请使用抽象工厂

通过构造函数注入的依赖项往往是长寿命的，但有时您需要一个短命的对象，或者基于仅在运行时已知的值构造依赖项。

有关详细信息，请参阅此。

仅在最后负责的时刻撰写

将对象分离到最后。通常，您可以等待并连接应用程序入口点中的所有内容。这被称为复合根。

详细信息如下：

我应该在哪里使用Ninject2+进行注入(以及如何安排模块？)
设计-使用温莎时应在何处登记物体

简化使用立面

如果您觉得所得到的API对于新手来说过于复杂，那么您总是可以提供一些外观类来封装常见的依赖项组合。

为了提供具有高度可发现性的灵活外观，可以考虑提供流畅的构建器。像这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public class MyFacade
{
private IMyDependency dep;

public MyFacade()
{
this.dep = new DefaultDependency();
}

public MyFacade WithDependency(IMyDependency dependency)
{
this.dep = dependency;
return this;
}

public Foo CreateFoo()
{
return new Foo(this.dep);
}
}

这将允许用户通过编写

1	var foo = new MyFacade().CreateFoo();

但是，可以很容易地发现，可以提供自定义依赖项，并且可以编写

1	var foo = new MyFacade().WithDependency(new CustomDependency()).CreateFoo();

如果您设想myFacade类封装了许多不同的依赖项，那么我希望它能够清楚地提供适当的默认值，同时仍然可以发现可扩展性。

在写下这个答案很久之后，我扩展了本文的概念，写了一篇关于DI友好库的较长的博客文章，以及一篇关于DI友好框架的配套文章。

相关讨论

虽然这在纸面上听起来很好，但根据我的经验，一旦你有许多内部组件以复杂的方式交互，你最终会遇到许多工厂需要管理，使得维护更加困难。另外，工厂必须管理他们创建的组件的生活方式，一旦将库安装到一个真正的容器中，这将与容器自己的生活方式管理冲突。工厂和正面挡住了真正的集装箱。
我还没有找到一个能完成所有这些工作的项目。
嗯，这就是我们在SafeWhere开发软件的方式，所以我们不分享您的经验…
我知道在设计使用DI/IOC时所涉及的一般原则。特别是，我询问了如何设计/简化其他用户对库的使用，他们可能会选择使用我喜欢的容器，如ninject或structuremap，或者其他一些替代方法。在维护适当的DI的同时，我可以通过哪些具体的方法来简化"高级"API的使用。Facade方法是我曾经调和过的，但问题是：Facade类是否直接依赖于实现？如果没有，他们是如何注入依赖关系的？
我更新了我的答案，详细阐述了立面部分-我希望能让它更清楚一点。
myFacade是否适合隐藏IOC容器实现，即让createFoo方法从容器中解析foo？
我认为立面应该是手工编码的，因为它们代表已知(并且可能是常见的)组件组合。不需要DI容器，因为所有东西都可以用手连接(想想可怜人的DI)。回想一下，Facade只是您的API用户的一个可选的便利类。高级用户可能仍然希望绕过外观，将组件连接到自己喜欢的地方。他们可能想使用自己的DI容器来实现这一点，所以我认为如果他们不打算使用特定的DI容器，那么将它强制应用到他们身上是不友好的。可能但不可取
还可以查看公共服务定位器
@Mauricioscheffer："工厂必须管理他们创造的组件的生活方式——至少是城堡的生活方式。温莎做到了，你必须使工厂的生活方式至少与它创造的组件一样长。"然后由这些对象的使用者来管理这些对象的释放(将它们传递给工厂)。这和工厂的情况不一样。对象的生活方式基本上取决于调用工厂的组件。我不确定这在任何DI框架中都会有很大的不同…
@MerlynmarganGraham：在IOC框架中，通常是容器管理生活方式，而不是组件调用工厂。这使事情简单多了。
@Markseeman，你是否应该重新表述"程序到接口"的原则，以便与你的后期接口保持一致，而不是抽象的。
这也许是我见过的最好的答案。
@Mauricioscheffer您不需要在周围建立工厂——您可以将这些工厂隐藏在工厂方法中，将它们连接到DI中，然后再次依赖于构造函数注入。这很容易用Castlewindsor完成，它将处理包括寿命在内的完整RRR循环。因此，如果切换DI容器，则只需要更改工厂方法。
@Ognyandimitrov注意到你正在回复一个几年前的线程。我现在甚至不再使用或推荐IOC了。整个问题及其答案现在都没有定论。
@毛里西奥谢弗，你在第一次评论中描述了我的问题。例如：2个模块：包含订单的电子商务和包含发票的会计。当发票更新(付款状态)时，我还希望更新订单(订单状态)。如果电子商务模块被"激活"，我如何使用DI，使我的Accounting.InvoiceLogic类只调用我的Ecommerce.OrderLogic。我的首选方案是，如果模块需要处于活动状态，那么只在DI中注册它们。但是在使用构造函数注入时，如果没有注册orderlogic，它将抛出一个错误。

术语"依赖注入"与IOC容器一点关系都没有，即使您倾向于看到它们一起提到。它只是意味着，不要像这样编写代码：

1
2
3
4
5
6
7
8
9
10
11
12
13

public class Service
{
public Service()
{
}

public void DoSomething()
{
SqlConnection connection = new SqlConnection("some connection string");
WindowsIdentity identity = WindowsIdentity.GetCurrent();
// Do something with connection and identity variables
}
}

你这样写：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class Service
{
public Service(IDbConnection connection, IIdentity identity)
{
this.Connection = connection;
this.Identity = identity;
}

public void DoSomething()
{
// Do something with Connection and Identity properties
}

protected IDbConnection Connection { get; private set; }
protected IIdentity Identity { get; private set; }
}

也就是说，编写代码时要做两件事：

每当您认为可能需要更改实现时，都依赖接口而不是类；

不是在类内创建这些接口的实例，而是将它们作为构造函数参数传递(或者，它们可以分配给公共属性；前者是构造函数注入，后者是属性注入)。

所有这些都不以任何DI库的存在为前提，也不会使没有DI库的代码编写起来更加困难。

如果您正在寻找一个这样的例子，只需查看.NET框架本身：

List执行IList。如果将类设计为使用IList(或IEnumerable)，则可以利用诸如延迟加载之类的概念，如linq to sql、linq to entities和nhibernate，通常都是通过属性注入实现的。一些框架类实际上接受一个IList作为构造函数参数，例如BindingList，它用于多个数据绑定功能。
linq-to-sql和ef完全围绕IDbConnection和相关接口构建，这些接口可以通过公共构造函数传入。不过，您不需要使用它们；默认的构造器只需将连接字符串放在配置文件中的某个地方就可以正常工作。
如果您曾经使用过WinForms组件，那么您将处理"服务"，如INameCreationService或IExtenderProviderService。你甚至不知道具体的类是什么。.NET实际上有自己的IOC容器IContainer用于此目的，Component类有一个GetService方法，它是实际的服务定位器。当然，没有任何东西可以阻止您在没有IContainer或特定定位器的情况下使用任何或所有这些接口。服务本身仅与容器松散耦合。
WCF中的契约完全围绕接口构建。实际的具体服务类通常由配置文件中的名称引用，该文件本质上是DI。许多人没有意识到这一点，但完全有可能用另一个IOC容器替换这个配置系统。也许更有趣的是，服务行为都是IServiceBehavior的实例，可以稍后添加。同样，您可以很容易地将其连接到IOC容器中并让它选择相关的行为，但是如果没有这样的行为，这个特性是完全可用的。

等等。你会发现在.NET中到处都是DI，只是通常情况下它是如此无缝地完成，以至于你甚至不认为它是DI。

如果您希望设计支持DI的库以获得最大的可用性，那么最好的建议可能是使用轻量级容器提供您自己的默认IOC实现。IContainer是一个很好的选择，因为它是.NET框架本身的一部分。

相关讨论

编辑：时间已经过去了，我现在意识到这是一个巨大的错误。IOC容器很糟糕，DI是处理副作用的非常糟糕的方法。实际上，这里的所有答案(以及问题本身)都应该避免。只需注意副作用，将它们与纯粹的代码分离，其他的事情要么就就位了，要么就是不相关和不必要的复杂性。

原始答案如下：

我在开发Solrnet时不得不面对同样的决定。我开始的目标是成为DI友好型和容器不可知型的，但是随着我添加越来越多的内部组件，内部工厂很快变得无法管理，结果产生的库是不灵活的。

最后，我编写了自己的非常简单的嵌入式IOC容器，同时还提供了一个温莎设施和一个Ninject模块。将库与其他容器集成只是正确连接组件的问题，因此我可以轻松地将它与autopac、unity、structuremap等集成。

这样做的缺点是，我失去了只使用new启动服务的能力。我还依赖于CommonServiceLocator，我本可以避免(将来可能会将其重构出来)，以使嵌入式容器更容易实现。

有关详细信息，请参阅此日志。

大众运输似乎也依赖类似的东西。它有一个IObjectBuilder接口，该接口实际上是CommonServiceLocator的IServicelocator，使用了更多的方法，然后它为每个容器实现这个接口，即NinObjectBuilder和一个常规模块/设施，即MassTransitModule。然后它依赖于IObjectBuilder来实例化它需要的东西。当然，这是一种有效的方法，但就我个人而言，我不太喜欢它，因为它实际上在容器周围传递了太多信息，将其用作服务定位器。

单轨铁路也实现了自己的集装箱，这实现了良好的旧ISeviceProvider。此容器通过公开已知服务的接口在整个框架中使用。为了得到具体的容器，它有一个内置的服务提供者定位器。温莎设施将此服务提供商定位器指向温莎，使其成为选定的服务提供商。

底线：没有完美的解决方案。与任何设计决策一样，这个问题要求在灵活性、可维护性和方便性之间取得平衡。

相关讨论

虽然我尊重你的意见，但我发现你过于笼统的"这里的所有其他答案都过时了，应该避免"非常幼稚。如果从那以后我们学到了什么，那就是依赖注入是语言限制的答案。在不改变或放弃当前语言的情况下，我们似乎需要DI来扁平化架构并实现模块化。国际奥委会作为一个总体概念，正是这些目标的结果，也是一个令人满意的目标。IOC容器对于IOC或DI都是绝对不必要的，它们的实用性取决于我们制作的模块组合。
@你提到我"极其幼稚"是不受欢迎的。我已经编写了复杂的应用程序，在C语言中没有DI或IOC，VB.NET，Java(你想的语言)需要"IOC很明显根据你的描述来判断"，这绝对不是语言限制。这是关于概念上的局限性。我邀请你学习函数式编程，而不是求助于自动寻的攻击和糟糕的论点。
我提到过，我觉得你的陈述很幼稚；这与你个人无关，完全与我的观点有关。请不要觉得被一个随便的陌生人侮辱了。暗示我对所有相关的函数式编程方法都一无所知也没有帮助；你不知道这一点，你就错了。我知道你在那里很有学问(很快看了一下你的博客)，这就是为什么我觉得一个表面上很有学问的人会说"我们不需要国际奥委会"这样的话很烦人。在函数编程中，IOC几乎无处不在。
以及一般的高级软件。事实上，功能语言(以及许多其他风格)确实证明了它们在没有DI的情况下解决IOC，我认为我们都同意这一点，这就是我想说的。如果在您提到的语言中没有DI，您是如何做到的？我假设不是使用ServiceLocator。如果您应用函数技术，那么您最终会得到相当于闭包的结果，闭包是依赖注入类(其中依赖项是封闭的变量)。还有别的吗？(我真的很好奇，因为我也不喜欢DI。)
IOC容器是全局可变字典，将参数性作为推理的工具，因此需要避免。"不要叫我们，我们会叫你"中的IOC(概念)在每次传递函数值时都会从技术上应用。代替DI，用ADT建模域，然后编写解释程序(C.F.免费)。
@当传递一个"di"函数时，如果你必须在haskell中用io来建模这个函数，那么问问你自己是否有一种避免io的方法。IO是一个表示性的tarpit。
完全同意所有计数。我分享了你对容器的看法(和现在几乎所有其他人一样)，并且看到了更高阶函数作为一种IOC的实现。我还需要考虑国际奥委会和口译之间的"同态"。但凭直觉，你的观点似乎很合理。不幸的是，当前"主流"语言中缺乏ADT支持(根据您给出的列表)，这使得这些方法难以想象。因此，我仍然困惑于如何在这些语言中避免DI而不失去好处。
@在大多数主流语言中，您可以很容易地将ADT编码为类的封闭层次结构(bugsquash.blogspot.com/2012/01/&hellip；)或变形(tonymorris.github.io/blog/posts/south-with-a-catmorphism)。只是更详细。

我要做的是以一种DI容器不可知论的方式设计我的库，以尽可能地限制对容器的依赖。这允许在DI容器上交换另一个容器(如果需要)。

然后向库的用户公开DI逻辑之上的层，以便他们可以使用您通过接口选择的任何框架。这样，他们仍然可以使用您公开的DI功能，并且可以自由地为自己的目的使用任何其他框架。

允许库的用户插入自己的DI框架对我来说似乎有点错误，因为它显著地增加了维护量。这也会比直接DI更像是一个插件环境。