dependency-injection - DI、构造函数注入(inject)、模块、设计模式

Question

我在参与的项目中遇到了一些架构问题。该项目是一个 ASP.NET MVC 2 应用程序，它依赖于 DI，尤其是依赖于 Unity 的构造函数注入(inject)。该应用程序分为几个模块(每个模块都是一组组件)，这些模块向其他模块公开服务。这些服务在应用程序启动时注册到 Unity。到现在为止没有什么特别的。假设我有这个(每个模块都是一个简化的程序集):

模块 A、模块 B。

ModuleA 使用以下方法公开服务“IServiceA”:

IServiceA(操作 1 - 操作 2 - 操作 3)

ModuleB 的 ServiceB 需要 ModuleA 的 IServiceA，它通过构造函数注入(inject)(具体实现)获得它。然后它使用它。

问题是当 ModuleA 被停用时(我们在数据库中检查模块是否在应用程序启动时为当前用户激活)，所以 serviceA 没有在 Unity 中注册。

然后我们在运行时出现异常，因为unity找不到一个IServiceA的注册，无法构造ServiceB。这是正常的。

我想知道有一套模式或最佳实践来处理它。我的第一个想法是摆脱 ServiceB 的构造函数注入(inject)。但是我应该使用对 ServiceA 的硬引用，但我不喜欢它，或者使用更糟糕的 ServiceLocator。我不想在 ModuleB 中检查 ServiceA 是否可用，因为我会检查许多其他服务，并且应该处理纯基础结构的代码。如果 serviceA 可用或不可用，我希望 ServiceB 运行相同的代码(不知道是否可能)。我查看了网关模式，但不知道这是否对我有帮助。

我们将不胜感激。

谢谢，

Answer 1

您需要某种默认实现，它可以在 ModuleA 停用时接管。 Null Object模式听起来非常合适。

只需先向 Unity 注册您的 NullServiceA。这将是默认的 IServiceA，除非被实际实现覆盖(我们称之为 ConcreteServiceA)。

对于更复杂的实现，您可以将 NullServiceA 和 ConcreteServiceA 包装在 Composite 中，或者可能是另一种形式的 Decorator根据可用性选择一个而不是另一个。

例如，您可以有一个 Composite，它始终使用注入(inject)其中的第一个(或最后一个)IServiceA 实例……或者选择标准可能基于某种元数据，该元数据确定模块是否被激活或停用(听起来该信息本身可以很好地适合假设的 IModule 接口(interface))。