c# - 寻找将温莎生活方式带入图书馆的方式

Question

我们有一个 web api 项目，它引用了一个在许多不同系统之间共享的库。

该库公开了一个“RegisterDependancies(IWindsorContainer container)”函数，调用该函数时将为该特定库注册所有依赖项。

因此，当 web api 应用程序启动时，它会进行自己的注册，然后调用共享库，类似于以下伪代码:

public void SetupWindsor(){

    IWindsorContainer container = new WindsorContainer();

    container.Register(Component.For<iFoo>().ImplementedBy<Foo>());

     SharedLibrary.RegisterDependancies(container);
}

共享库函数看起来有点像这样:

public void RegisterDependancies(IWindsorContainer container)
{
    container.Register(Component.For<iBar>().ImplementedBy<Bar>());
    //In this instance Bar is internal so could not be registered by the api project.
}

我们现在希望 web api 项目使用 PerWebRequest 生活方式，但其他系统可能希望使用不同的生活方式(这个决定将取决于编写客户端应用程序的人 - 共享库将用于控制台和 Windows 应用程序 -所以 perwebrequest 不适合他们使用)

我们想更改 RegisterDependancies 方法，以便我们可以传递生活方式。

是否可以使用 PerWebRequest 生活方式来做到这一点？我们中的一些人看了一眼，却不知道如何去做 - 尽管过去曾做过类似的事情而没有出现统一问题。

我们正在寻找一种方法来解决所描述的问题，或者如果有更好的方法来解决这个问题也会有所帮助。

编辑以澄清，共享库将接口(interface) ​​IBar 定义为公共(public)接口(interface)，但将类 Bar 定义为内部接口(interface)，因此 API 无法进行注册 - 除非温莎有一些我不知道的魔法。

Answer 1

the shared library defines the interface IBar as public but the class Bar as internal so the API cannot do the registration

让我们花点时间研究一下这个设计决策。虽然没有外部调用者可以创建 Bar 对象，但他们可以创建 IBar 对象:

IWindsorContainer container = new WindsorContainer();
SharedLibrary.RegisterDependancies(container);
IBar bar = container.Resolve<IBar>();

保留 Bar 类 internal 的原因可能有多种，但既然您已经可以运行上面的代码，为什么不简单地让共享库公开一个工厂？

IBar bar = SharedLibrary.CreateBar();

那会简单得多，并且可以将共享库与容器分离。一般来说，这是我能给出的关于依赖注入(inject)和可重用库的最佳建议:使用依赖注入(inject)模式，而不是容器。看我的文章DI-Friendly Library了解更多详情。

如果您仍想在宿主项目(例如 Wep API 项目)中使用 DI 容器，您可以针对该静态工厂方法注册 IBar。

内部类

人们想要保留一些类 internal 是有正当理由的，但我经常看到代码库中的类是 internal 的，原因不明。我对几十年的 C# 代码的经验是，类是 internal 没有充分理由的情况远远超过有充分理由的情况。

Bar 真的必须是内部的吗？为什么？

从 OP 可以清楚地看出 IBar 是由 Bar 实现的。这可能是将问题简化为基本要素的人工产物(干得好，顺便说一句)，但我的印象是Bar 是唯一的 实现 IBar 的类。是这样吗？

如果是这样，Bar 类必须公开IBar 定义的方法。这样，类的API就已经公开了，为什么要隐藏类呢？那么，唯一隐藏的是构造函数...

完美 Storm

有时，当我提出上述建议时，我会得到这样的答复，即这不是问题的重点。问题是关于如何改变温莎城堡的生活方式(顺便说一句，you can)。

另一方面，这个问题几乎是完美的(小) Storm ，它说明了为什么可重用库不应该依赖 DI 容器:

• 该库应该可以在不止一种环境中使用(网络、控制台、桌面等)
• 图书馆依赖于温莎城堡
• 接口(interface)是公共(public)的，但实现类不是

这使事情变得复杂 - 因此 Stack Overflow 上出现了这个问题。

我最好的建议是让事情保持简单。消除对 CaSTLe Windsor 的依赖将使库开发和重用更容易，而不是更难。

如果您公开大多数库类，使用库会更容易。