带有太多构造函数参数的 Unity 注入
Unity injection with too many constructor parameters
我有以下与 Unity 相关的问题。下面的代码存根设置了基本场景，问题在底部。
注意，[Dependency] 属性不适用于下面的示例并导致 WhosebugException，但构造函数注入确实有效。
注意(2) 下面的一些评论开始分配 "labels"，比如代码味道，糟糕的设计等等......所以，为了避免混淆，这里首先是没有任何设计的业务设置.
这个问题似乎甚至在一些最著名的 C# 专家中引起了激烈的争论。事实上，这个问题远远超出了 C#，它更多地属于纯计算机科学。问题基于服务定位器模式和纯依赖注入模式之间众所周知的 "battle"：https://martinfowler.com/articles/injection.html vs http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/ and a subsequent update to remedy the situation when the dependency injection becomes too complicated: http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/
这是一种情况，它与后两个描述的内容不太相符，但似乎完全符合第一个。
我收集了大量（50 多个）我称之为微服务的东西。如果你有更好的名字，请在阅读时"apply"。他们每个人都对一个对象进行操作，我们称之为引用。但是，元组 (context + quote) 似乎更合适。报价是一个业务对象，它被处理并序列化到数据库中，上下文是一些支持信息，在处理报价时需要这些信息，但不会保存到数据库中。其中一些支持信息实际上可能来自数据库或某些第三方服务。这无关紧要。装配线作为一个真实世界的例子浮现在脑海中：装配工人（微服务）接收一些输入（指令（上下文）+零件（报价）），处理它（根据指令对零件做某事和/或修改指令）如果成功或在出现问题时丢弃它（引发异常），则进一步传递它。微服务最终被捆绑成少量（大约 5 个）高级服务。这种方法线性化了一些非常复杂的业务对象的处理，并允许将每个微服务与所有其他微服务分开测试：只需给它一个输入状态并测试它是否产生预期的输出。
这里是有趣的地方。由于涉及的步骤很多，高级服务开始依赖许多微服务：10 多个甚至更多。这种依赖是自然的，它只是反映了底层业务对象的复杂性。除此之外，几乎可以不断地添加/删除微服务：基本上，它们是一些业务规则，几乎像水一样流动。
这与 Mark 上面的建议严重冲突：如果我有 10 多个有效独立的规则应用于某些高级服务中的报价，那么，根据第三篇博客，我应该将它们聚合到一些逻辑组中，假设不超过 3-4 个，而不是通过构造函数注入所有 10 个以上。但是没有逻辑组！虽然一些规则是松散依赖的，但大多数规则不是，因此人为地将它们捆绑在一起弊大于利。
加上规则经常变化，这成为维护的噩梦：每次规则变化时都必须更新所有真实/模拟调用。
而且我什至没有提到规则取决于美国各州，因此理论上，大约有 50 个规则集合，每个州和每个工作流都有一个集合。虽然有些规则在所有州之间共享（例如 "save quote to the database"），但还有很多州特定的规则。
这是一个非常简单的例子。
引用 - 业务对象，已保存到数据库中。
public class Quote
{
public string SomeQuoteData { get; set; }
// ...
}
微服务。他们每个人都执行一些小的更新来引用。也可以从一些较低级别的微服务构建更高级别的服务。
public interface IService_1
{
Quote DoSomething_1(Quote quote);
}
// ...
public interface IService_N
{
Quote DoSomething_N(Quote quote);
}
所有的微服务都继承这个接口。
public interface IQuoteProcessor
{
List<Func<Quote, Quote>> QuotePipeline { get; }
Quote ProcessQuote(Quote quote = null);
}
// Low level quote processor. It does all workflow related work.
public abstract class QuoteProcessor : IQuoteProcessor
{
public abstract List<Func<Quote, Quote>> QuotePipeline { get; }
public Quote ProcessQuote(Quote quote = null)
{
// Perform Aggregate over QuotePipeline.
// That applies each step from workflow to a quote.
return quote;
}
}
高级 "workflow" 服务之一。
public interface IQuoteCreateService
{
Quote CreateQuote(Quote quote = null);
}
及其实际实现，其中我们使用了许多低级微服务。
public class QuoteCreateService : QuoteProcessor, IQuoteCreateService
{
protected IService_1 Service_1;
// ...
protected IService_N Service_N;
public override List<Func<Quote, Quote>> QuotePipeline =>
new List<Func<Quote, Quote>>
{
Service_1.DoSomething_1,
// ...
Service_N.DoSomething_N
};
public Quote CreateQuote(Quote quote = null) =>
ProcessQuote(quote);
}
实现DI主要有两种方式：
标准方法是通过构造函数注入所有依赖项：
public QuoteCreateService(
IService_1 service_1,
// ...
IService_N service_N
)
{
Service_1 = service_1;
// ...
Service_N = service_N;
}
然后用Unity注册所有类型：
public static class UnityHelper
{
public static void RegisterTypes(this IUnityContainer container)
{
container.RegisterType<IService_1, Service_1>(
new ContainerControlledLifetimeManager());
// ...
container.RegisterType<IService_N, Service_N>(
new ContainerControlledLifetimeManager());
container.RegisterType<IQuoteCreateService, QuoteCreateService>(
new ContainerControlledLifetimeManager());
}
}
然后 Unity 将执行其 "magic" 并在 运行 时解析所有服务。问题是目前我们有大约 30 个这样的微服务，而且这个数字预计还会增加。随后，一些构造函数已经注入了 10 多个服务。这不方便维护，模拟等...
当然，可以使用这里的想法：http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/但是，微服务彼此之间并没有真正相关，因此将它们捆绑在一起是一个没有任何理由的人为过程。此外，它还会破坏使整个工作流线性和独立的目的（微服务获取当前 "state"，然后用引用执行一些操作，然后继续前进）。 None 他们关心他们之前或之后的任何其他微服务。
另一个想法似乎是创建一个 "service repository":
public interface IServiceRepository
{
IService_1 Service_1 { get; set; }
// ...
IService_N Service_N { get; set; }
IQuoteCreateService QuoteCreateService { get; set; }
}
public class ServiceRepository : IServiceRepository
{
protected IUnityContainer Container { get; }
public ServiceRepository(IUnityContainer container)
{
Container = container;
}
private IService_1 _service_1;
public IService_1 Service_1
{
get => _service_1 ?? (_service_1 = Container.Resolve<IService_1>());
set => _service_1 = value;
}
// ...
}
然后用Unity注册，把所有相关服务的构造函数改成这样：
public QuoteCreateService(IServiceRepository repo)
{
Service_1 = repo.Service_1;
// ...
Service_N = repo.Service_N;
}
这种方法（与前一种方法相比）的好处如下：
所有微服务和更高级别的服务都可以以统一的形式创建：可以轻松添加/删除新的微服务，而无需修复服务的构造函数调用和所有单元测试。随后，维护和复杂性降低。
由于接口IServiceRepository，很容易创建一个自动化单元测试，它将遍历所有属性并验证所有服务是否可以实例化，这意味着不会有讨厌的运行时间惊喜
这种方法的问题是它开始看起来很像服务定位器，有些人认为这是一种反模式：http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/然后人们开始争辩说必须建立所有依赖关系显式而不是隐藏，如 ServiceRepository.
我该怎么办？
Unity 支持 属性 注入。无需将所有这些值传递给构造函数，只需使用 [Dependency] 属性提供 public setter。这允许您根据需要添加任意数量的注入，而无需更新构造函数。
public class QuoteCreateService : QuoteProcessor, IQuoteCreateService
{
[Dependency]
protected IService_1 Service_1 { get; public set; }
// ...
[Dependency]
protected IService_N Service_N; { get; public set; }
public override QuoteUpdaterList QuotePipeline =>
new QuoteUpdaterList
{
Service_1.DoSomething_1,
// ...
Service_N.DoSomething_N
};
public Quote CreateQuote(Quote quote = null) =>
ProcessQuote(quote);
}
我只创建一个接口：
public interface IDoSomethingAble
{
Quote DoSomething(Quote quote);
}
和一个聚合：
public interface IDoSomethingAggregate : IDoSomethingAble {}
public class DoSomethingAggregate : IDoSomethingAggregate
{
private IEnumerable<IDoSomethingAble> somethingAbles;
public class DoSomethingAggregate(IEnumerable<IDoSomethingAble> somethingAbles)
{
_somethingAbles = somethingAbles;
}
public Quote DoSomething(Quote quote)
{
foreach(var somethingAble in _somethingAbles)
{
somethingAble.DoSomething(quote);
}
return quote;
}
}
注意：依赖注入并不是说，你需要处处使用它。
我会去工厂：
public class DoSomethingAggregateFactory
{
public IDoSomethingAggregate Create()
{
return new DoSomethingAggregate(GetItems());
}
private IEnumerable<IDoSomethingAble> GetItems()
{
yield return new Service1();
yield return new Service2();
yield return new Service3();
yield return new Service4();
yield return new Service5();
}
}
其他所有内容（未注入构造函数的）都隐藏了显式依赖项。
作为最后的手段，您还可以创建一些 DTO 对象，通过构造函数注入每个需要的服务（但只能注入一次）。
这样您就可以请求 ProcessorServiceScope 并使所有服务可用，而无需为每个 class:
创建 ctor 逻辑
public class ProcessorServiceScope
{
public Service1 Service1 {get;};
public ServiceN ServiceN {get;};
public ProcessorServiceScope(Service1 service1, ServiceN serviceN)
{
Service1 = service1;
ServiceN = serviceN;
}
}
public class Processor1
{
public Processor1(ProcessorServiceScope serviceScope)
{
//...
}
}
public class ProcessorN
{
public ProcessorN(ProcessorServiceScope serviceScope)
{
//...
}
}
看起来像ServiceLocator，但它没有隐藏依赖关系，所以我觉得这样还可以。
考虑列出的各种接口方法：
Quote DoSomething_1(Quote quote);
Quote DoSomething_N(Quote quote);
Quote ProcessQuote(Quote quote = null)
Quote CreateQuote(Quote quote = null);
除了名字，它们完全相同。为什么要把事情搞得这么复杂？考虑到 Reused Abstractions Principle，我认为如果你有更少的抽象和更多的实现会更好。
因此，引入一个抽象：
public interface IQuoteProcessor
{
Quote ProcessQuote(Quote quote);
}
这是一个很好的抽象，因为它是一个 endomorphism over Quote, which we know is composable. You can always create a Composite of an endomorphism:
public class CompositeQuoteProcessor : IQuoteProcessor
{
private readonly IReadOnlyCollection<IQuoteProcessor> processors;
public CompositeQuoteProcessor(params IQuoteProcessor[] processors)
{
this.processors = processors ?? throw new ArgumentNullException(nameof(processors));
}
public Quote ProcessQuote(Quote quote)
{
var q = quote;
foreach (var p in processors)
q = p.ProcessQuote(q);
return q;
}
}
至此，我想您基本上已经完成了。您现在可以组合各种服务（在 OP 中称为 microservices 的服务）。这是一个简单的例子：
var processor = new CompositeQuoteProcessor(new Service1(), new Service2());
这样的组合应该放在应用程序的 Composition Root.
各种服务可以有自己的依赖关系：
var processor =
new CompositeQuoteProcessor(
new Service3(
new Foo()),
new Service4());
如果有用的话，您甚至可以嵌套复合材料：
var processor =
new CompositeQuoteProcessor(
new CompositeQuoteProcessor(
new Service1(),
new Service2()),
new CompositeQuoteProcessor(
new Service3(
new Foo()),
new Service4()));
这很好地解决了 构造函数过度注入 代码异味，因为 CompositeQuoteProcessor class 只有一个依赖项。但是，由于该单一依赖项是一个集合，您可以任意组合许多其他处理器。
在这个回答中，我完全忽略了Unity。依赖注入是软件设计的问题。如果一个 DI 容器不能轻易地组成一个好的设计，你最好使用 Pure DI，我在这里已经暗示了。
如果您必须使用 Unity，您始终可以创建从 CompositeQuoteProcessor 派生的具体 classes 并采用 Concrete Dependencies:
public class SomeQuoteProcessor1 : CompositeQuoteProcessor
{
public SomeQuoteProcessor1(Service1 service1, Service3 service3) :
base(service1, service3)
{
}
}
Unity 应该能够自动连接 class，然后...
我从没想过我会回答我自己的问题，尽管很大一部分功劳应该归功于 https://softwareengineering.stackexchange.com/users/115084/john-wu - 他是我的思想方向正确的人。
尽管如此，自从我提出问题以来已经过去了将近两年，虽然我在提出问题后稍微构建了问题的解决方案（并感谢所有回答的人），但大多数人花了一年多的时间我工作的公司中的开发人员真正了解它是如何工作的以及它做了什么（是的，他们都远高于平均水平的开发人员，是的，代码是用纯 C# 编写的，没有外部库）。因此，我认为这对于可能具有类似业务场景的其他人来说可能很重要。
正如问题中提到的，我们问题的根源是我们正在处理的参数space太大了。我们有大约 6-8 个我们称之为工作流的值（称为 W），大约有 30-40 个我们称为状态配置的值（称为 S）——这是美国州代码和其他两个参数的组合，虽然并非所有三元组都是可能的（状态配置的实际内容无关紧要），我们称之为风险规则（称为 R）的大约 30-50 个值 - 该值取决于产品，但这也无关紧要，因为不同的产品区别对待。
所以，参数space的总维数是N = W * S * R，大约在10K左右（我不太在意一个精确的值）。这意味着当代码 运行s 时，我们大约需要以下内容：对于每个工作流（显然一次只有一个 运行ning 但它们都在某个时间做 运行）和每个状态配置（同样一次只有一个 运行ning 但它们中的任何一个都可以 运行 在某个时间）我们需要评估所有风险规则，这些规则与该工作流和该状态配置相关.
嗯，如果参数 space 的维数大约是 N，那么覆盖整个 space 所需的测试数量至少是 N 的数量级。这是究竟遗留代码和测试试图做什么以及导致问题的原因。
答案是纯数学，而不是纯计算机科学，它基于所谓的可分离 spaces: https://en.wikipedia.org/wiki/Separable_space and what in the group theory terms is called irreducible representation: https://en.wikipedia.org/wiki/Irreducible_representation 。虽然我不得不承认，后者更像是一种灵感，而不是群论的实际应用。
如果你已经失去了我，那很好。请在继续之前阅读上面提到的数学。
这里的space可分性是指我们可以选择这样一个spaceN，使得子space的W、S、R成为独立的（或者可分离的）。据我所知，对于我们在 CS 中处理的有限 spaces，这总是可以完成的。
这意味着我们可以将 N space 描述为例如S 列出（或集合）一些规则，而通过为每个规则分配一组适用的工作流，每个规则适用于某些 W 工作流。是的，如果我们有一些原本应该应用于某些奇怪的工作流和状态配置组合的糟糕规则，那么我们可以将它们拆分为多个规则，这样就可以保持可分离性。
当然，这可以概括，但我将跳过细节，因为它们无关紧要。
说到这里，有人可能会疑惑，这有什么意义。好吧，如果我们可以将 N 维 space（在我们的例子中 N 大约是 10K）拆分成独立的子 space，那么魔法就会发生，而不是按照 N = W *S 的顺序书写* R tests to cover the whole parameter space 我们只需要按照W + S + R tests的顺序写就可以覆盖整个参数space。 在我们的例子中，差异大约是 100X。
但这还不是全部。正如我们可以在集合或列表（取决于需要）的概念中描述 subspaces，这自然会把我们带到无用测试的概念。
等等，我刚刚是在说无用的测试吗？是的，我做到了。让我解释。一个典型的 TDD 范例是，如果代码失败，那么我们需要做的第一件事就是创建一个测试，它会发现那个错误。好吧，如果代码是由静态列表或集合（== 列表或集合硬编码在代码中）描述的，并且测试将由来自 list/set 的身份转换来描述，那么这使得这样一个测试无用，因为它必须重复原来的 list/set…
状态配置形成了一种历史模式，例如，我们在 2018 年的某个时候对 CA 的状态制定了一些规则集。这组规则可能会在2019 年和 2020 年的一些规则。这些变化很小：一组规则可能会增加或丢失一些规则 and/or 规则可能会稍微调整一下，例如如果我们将某个值与某个阈值进行比较，那么对于某些状态配置，该阈值的值可能会在某个时候更改。一旦规则或规则集发生变化，它就应该保持原样，直到再次发生变化。同时一些其他的规则可能会被改变，每一个这样的改变都需要引入我们所说的状态配置。因此，对于美国的每个州，我们都订购了这些州配置的集合（列表），并且对于每个州配置，我们都有一组规则。大多数规则不会改变，但其中一些规则会如所述偶尔发生变化。一种自然的 IOC 方法是使用 IOC 容器注册每个规则集合和每个状态配置的每个规则，例如Unity 使用状态配置的唯一“名称”和规则/集合名称的组合（我们实际上 运行 在工作流期间有多个规则集合），而每个规则已经有一个工作流集合，它应该是适用的。然后，当给定状态配置和给定工作流的代码 运行s 时，我们可以将集合从 Unity 中拉出。然后一个集合包含应为 运行 的规则的名称。然后将规则的名称与状态配置的名称结合起来，我们可以从 Unity 中提取实际规则，过滤集合以仅留下适用于给定工作流的规则，然后应用所有规则。
这里发生的是规则名称/集合名称形成一些封闭集，并且通过这种方式描述它们会大大受益。我们显然不想手动为每个状态配置注册每个规则/集合，因为那会很乏味且容易出错。所以我们使用所谓的“规范化器”。假设我们有一个通用规则——这是一个对所有状态配置都相同的规则。然后我们仅按名称注册它，规范器将“自动”为所有状态配置注册它。历史版本控制也是如此。一旦我们通过规则/集合名称+状态配置向 Unity 注册规则/集合，规范器将填补空白，直到我们在稍后的某个状态配置更改规则。
这样一来，每一条规则都变得极其简单。他们中的大多数有零个或一个注入的构造函数参数，其中一些有两个，而且我只知道一个规则有三个注入参数。由于规则是独立的，非常简单，规则的测试也变得非常简单。
我们确实有一些想法可以让我在上面写的任何东西的核心开源，只要它能为社区带来一些价值...
我有以下与 Unity 相关的问题。下面的代码存根设置了基本场景，问题在底部。
注意，[Dependency] 属性不适用于下面的示例并导致 WhosebugException，但构造函数注入确实有效。
注意(2) 下面的一些评论开始分配 "labels"，比如代码味道，糟糕的设计等等......所以，为了避免混淆，这里首先是没有任何设计的业务设置.
这个问题似乎甚至在一些最著名的 C# 专家中引起了激烈的争论。事实上，这个问题远远超出了 C#，它更多地属于纯计算机科学。问题基于服务定位器模式和纯依赖注入模式之间众所周知的 "battle"：https://martinfowler.com/articles/injection.html vs http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/ and a subsequent update to remedy the situation when the dependency injection becomes too complicated: http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/
这是一种情况，它与后两个描述的内容不太相符，但似乎完全符合第一个。
我收集了大量（50 多个）我称之为微服务的东西。如果你有更好的名字，请在阅读时"apply"。他们每个人都对一个对象进行操作，我们称之为引用。但是，元组 (context + quote) 似乎更合适。报价是一个业务对象，它被处理并序列化到数据库中，上下文是一些支持信息，在处理报价时需要这些信息，但不会保存到数据库中。其中一些支持信息实际上可能来自数据库或某些第三方服务。这无关紧要。装配线作为一个真实世界的例子浮现在脑海中：装配工人（微服务）接收一些输入（指令（上下文）+零件（报价）），处理它（根据指令对零件做某事和/或修改指令）如果成功或在出现问题时丢弃它（引发异常），则进一步传递它。微服务最终被捆绑成少量（大约 5 个）高级服务。这种方法线性化了一些非常复杂的业务对象的处理，并允许将每个微服务与所有其他微服务分开测试：只需给它一个输入状态并测试它是否产生预期的输出。
这里是有趣的地方。由于涉及的步骤很多，高级服务开始依赖许多微服务：10 多个甚至更多。这种依赖是自然的，它只是反映了底层业务对象的复杂性。除此之外，几乎可以不断地添加/删除微服务：基本上，它们是一些业务规则，几乎像水一样流动。
这与 Mark 上面的建议严重冲突：如果我有 10 多个有效独立的规则应用于某些高级服务中的报价，那么，根据第三篇博客，我应该将它们聚合到一些逻辑组中，假设不超过 3-4 个，而不是通过构造函数注入所有 10 个以上。但是没有逻辑组！虽然一些规则是松散依赖的，但大多数规则不是，因此人为地将它们捆绑在一起弊大于利。
加上规则经常变化，这成为维护的噩梦：每次规则变化时都必须更新所有真实/模拟调用。
而且我什至没有提到规则取决于美国各州，因此理论上，大约有 50 个规则集合，每个州和每个工作流都有一个集合。虽然有些规则在所有州之间共享（例如 "save quote to the database"），但还有很多州特定的规则。
这是一个非常简单的例子。
引用 - 业务对象，已保存到数据库中。
public class Quote
{
public string SomeQuoteData { get; set; }
// ...
}
微服务。他们每个人都执行一些小的更新来引用。也可以从一些较低级别的微服务构建更高级别的服务。
public interface IService_1
{
Quote DoSomething_1(Quote quote);
}
// ...
public interface IService_N
{
Quote DoSomething_N(Quote quote);
}
所有的微服务都继承这个接口。
public interface IQuoteProcessor
{
List<Func<Quote, Quote>> QuotePipeline { get; }
Quote ProcessQuote(Quote quote = null);
}
// Low level quote processor. It does all workflow related work.
public abstract class QuoteProcessor : IQuoteProcessor
{
public abstract List<Func<Quote, Quote>> QuotePipeline { get; }
public Quote ProcessQuote(Quote quote = null)
{
// Perform Aggregate over QuotePipeline.
// That applies each step from workflow to a quote.
return quote;
}
}
高级 "workflow" 服务之一。
public interface IQuoteCreateService
{
Quote CreateQuote(Quote quote = null);
}
及其实际实现，其中我们使用了许多低级微服务。
public class QuoteCreateService : QuoteProcessor, IQuoteCreateService
{
protected IService_1 Service_1;
// ...
protected IService_N Service_N;
public override List<Func<Quote, Quote>> QuotePipeline =>
new List<Func<Quote, Quote>>
{
Service_1.DoSomething_1,
// ...
Service_N.DoSomething_N
};
public Quote CreateQuote(Quote quote = null) =>
ProcessQuote(quote);
}
实现DI主要有两种方式：
标准方法是通过构造函数注入所有依赖项：
public QuoteCreateService(
IService_1 service_1,
// ...
IService_N service_N
)
{
Service_1 = service_1;
// ...
Service_N = service_N;
}
然后用Unity注册所有类型：
public static class UnityHelper
{
public static void RegisterTypes(this IUnityContainer container)
{
container.RegisterType<IService_1, Service_1>(
new ContainerControlledLifetimeManager());
// ...
container.RegisterType<IService_N, Service_N>(
new ContainerControlledLifetimeManager());
container.RegisterType<IQuoteCreateService, QuoteCreateService>(
new ContainerControlledLifetimeManager());
}
}
然后 Unity 将执行其 "magic" 并在 运行 时解析所有服务。问题是目前我们有大约 30 个这样的微服务，而且这个数字预计还会增加。随后，一些构造函数已经注入了 10 多个服务。这不方便维护，模拟等...
当然，可以使用这里的想法：http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/但是，微服务彼此之间并没有真正相关，因此将它们捆绑在一起是一个没有任何理由的人为过程。此外，它还会破坏使整个工作流线性和独立的目的（微服务获取当前 "state"，然后用引用执行一些操作，然后继续前进）。 None 他们关心他们之前或之后的任何其他微服务。
另一个想法似乎是创建一个 "service repository":
public interface IServiceRepository
{
IService_1 Service_1 { get; set; }
// ...
IService_N Service_N { get; set; }
IQuoteCreateService QuoteCreateService { get; set; }
}
public class ServiceRepository : IServiceRepository
{
protected IUnityContainer Container { get; }
public ServiceRepository(IUnityContainer container)
{
Container = container;
}
private IService_1 _service_1;
public IService_1 Service_1
{
get => _service_1 ?? (_service_1 = Container.Resolve<IService_1>());
set => _service_1 = value;
}
// ...
}
然后用Unity注册，把所有相关服务的构造函数改成这样：
public QuoteCreateService(IServiceRepository repo)
{
Service_1 = repo.Service_1;
// ...
Service_N = repo.Service_N;
}
这种方法（与前一种方法相比）的好处如下：
所有微服务和更高级别的服务都可以以统一的形式创建：可以轻松添加/删除新的微服务，而无需修复服务的构造函数调用和所有单元测试。随后，维护和复杂性降低。
由于接口IServiceRepository，很容易创建一个自动化单元测试，它将遍历所有属性并验证所有服务是否可以实例化，这意味着不会有讨厌的运行时间惊喜
这种方法的问题是它开始看起来很像服务定位器，有些人认为这是一种反模式：http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/然后人们开始争辩说必须建立所有依赖关系显式而不是隐藏，如 ServiceRepository.
我该怎么办？
Unity 支持 属性 注入。无需将所有这些值传递给构造函数，只需使用 [Dependency] 属性提供 public setter。这允许您根据需要添加任意数量的注入，而无需更新构造函数。
public class QuoteCreateService : QuoteProcessor, IQuoteCreateService
{
[Dependency]
protected IService_1 Service_1 { get; public set; }
// ...
[Dependency]
protected IService_N Service_N; { get; public set; }
public override QuoteUpdaterList QuotePipeline =>
new QuoteUpdaterList
{
Service_1.DoSomething_1,
// ...
Service_N.DoSomething_N
};
public Quote CreateQuote(Quote quote = null) =>
ProcessQuote(quote);
}
我只创建一个接口：
public interface IDoSomethingAble
{
Quote DoSomething(Quote quote);
}
和一个聚合：
public interface IDoSomethingAggregate : IDoSomethingAble {}
public class DoSomethingAggregate : IDoSomethingAggregate
{
private IEnumerable<IDoSomethingAble> somethingAbles;
public class DoSomethingAggregate(IEnumerable<IDoSomethingAble> somethingAbles)
{
_somethingAbles = somethingAbles;
}
public Quote DoSomething(Quote quote)
{
foreach(var somethingAble in _somethingAbles)
{
somethingAble.DoSomething(quote);
}
return quote;
}
}
注意：依赖注入并不是说，你需要处处使用它。
我会去工厂：
public class DoSomethingAggregateFactory
{
public IDoSomethingAggregate Create()
{
return new DoSomethingAggregate(GetItems());
}
private IEnumerable<IDoSomethingAble> GetItems()
{
yield return new Service1();
yield return new Service2();
yield return new Service3();
yield return new Service4();
yield return new Service5();
}
}
其他所有内容（未注入构造函数的）都隐藏了显式依赖项。
作为最后的手段，您还可以创建一些 DTO 对象，通过构造函数注入每个需要的服务（但只能注入一次）。
这样您就可以请求 ProcessorServiceScope 并使所有服务可用，而无需为每个 class:
public class ProcessorServiceScope
{
public Service1 Service1 {get;};
public ServiceN ServiceN {get;};
public ProcessorServiceScope(Service1 service1, ServiceN serviceN)
{
Service1 = service1;
ServiceN = serviceN;
}
}
public class Processor1
{
public Processor1(ProcessorServiceScope serviceScope)
{
//...
}
}
public class ProcessorN
{
public ProcessorN(ProcessorServiceScope serviceScope)
{
//...
}
}
看起来像ServiceLocator，但它没有隐藏依赖关系，所以我觉得这样还可以。
考虑列出的各种接口方法：
Quote DoSomething_1(Quote quote);
Quote DoSomething_N(Quote quote);
Quote ProcessQuote(Quote quote = null)
Quote CreateQuote(Quote quote = null);
除了名字，它们完全相同。为什么要把事情搞得这么复杂？考虑到 Reused Abstractions Principle，我认为如果你有更少的抽象和更多的实现会更好。
因此，引入一个抽象：
public interface IQuoteProcessor
{
Quote ProcessQuote(Quote quote);
}
这是一个很好的抽象，因为它是一个 endomorphism over Quote, which we know is composable. You can always create a Composite of an endomorphism:
public class CompositeQuoteProcessor : IQuoteProcessor
{
private readonly IReadOnlyCollection<IQuoteProcessor> processors;
public CompositeQuoteProcessor(params IQuoteProcessor[] processors)
{
this.processors = processors ?? throw new ArgumentNullException(nameof(processors));
}
public Quote ProcessQuote(Quote quote)
{
var q = quote;
foreach (var p in processors)
q = p.ProcessQuote(q);
return q;
}
}
至此，我想您基本上已经完成了。您现在可以组合各种服务（在 OP 中称为 microservices 的服务）。这是一个简单的例子：
var processor = new CompositeQuoteProcessor(new Service1(), new Service2());
这样的组合应该放在应用程序的 Composition Root.
各种服务可以有自己的依赖关系：
var processor =
new CompositeQuoteProcessor(
new Service3(
new Foo()),
new Service4());
如果有用的话，您甚至可以嵌套复合材料：
var processor =
new CompositeQuoteProcessor(
new CompositeQuoteProcessor(
new Service1(),
new Service2()),
new CompositeQuoteProcessor(
new Service3(
new Foo()),
new Service4()));
这很好地解决了 构造函数过度注入 代码异味，因为 CompositeQuoteProcessor class 只有一个依赖项。但是，由于该单一依赖项是一个集合，您可以任意组合许多其他处理器。
在这个回答中，我完全忽略了Unity。依赖注入是软件设计的问题。如果一个 DI 容器不能轻易地组成一个好的设计，你最好使用 Pure DI，我在这里已经暗示了。
如果您必须使用 Unity，您始终可以创建从 CompositeQuoteProcessor 派生的具体 classes 并采用 Concrete Dependencies:
public class SomeQuoteProcessor1 : CompositeQuoteProcessor
{
public SomeQuoteProcessor1(Service1 service1, Service3 service3) :
base(service1, service3)
{
}
}
Unity 应该能够自动连接 class，然后...
我从没想过我会回答我自己的问题，尽管很大一部分功劳应该归功于 https://softwareengineering.stackexchange.com/users/115084/john-wu - 他是我的思想方向正确的人。
尽管如此，自从我提出问题以来已经过去了将近两年，虽然我在提出问题后稍微构建了问题的解决方案（并感谢所有回答的人），但大多数人花了一年多的时间我工作的公司中的开发人员真正了解它是如何工作的以及它做了什么（是的，他们都远高于平均水平的开发人员，是的，代码是用纯 C# 编写的，没有外部库）。因此，我认为这对于可能具有类似业务场景的其他人来说可能很重要。
正如问题中提到的，我们问题的根源是我们正在处理的参数space太大了。我们有大约 6-8 个我们称之为工作流的值（称为 W），大约有 30-40 个我们称为状态配置的值（称为 S）——这是美国州代码和其他两个参数的组合，虽然并非所有三元组都是可能的（状态配置的实际内容无关紧要），我们称之为风险规则（称为 R）的大约 30-50 个值 - 该值取决于产品，但这也无关紧要，因为不同的产品区别对待。
所以，参数space的总维数是N = W * S * R，大约在10K左右（我不太在意一个精确的值）。这意味着当代码 运行s 时，我们大约需要以下内容：对于每个工作流（显然一次只有一个 运行ning 但它们都在某个时间做 运行）和每个状态配置（同样一次只有一个 运行ning 但它们中的任何一个都可以 运行 在某个时间）我们需要评估所有风险规则，这些规则与该工作流和该状态配置相关.
嗯，如果参数 space 的维数大约是 N，那么覆盖整个 space 所需的测试数量至少是 N 的数量级。这是究竟遗留代码和测试试图做什么以及导致问题的原因。 答案是纯数学，而不是纯计算机科学，它基于所谓的可分离 spaces: https://en.wikipedia.org/wiki/Separable_space and what in the group theory terms is called irreducible representation: https://en.wikipedia.org/wiki/Irreducible_representation 。虽然我不得不承认，后者更像是一种灵感，而不是群论的实际应用。
如果你已经失去了我，那很好。请在继续之前阅读上面提到的数学。
这里的space可分性是指我们可以选择这样一个spaceN，使得子space的W、S、R成为独立的（或者可分离的）。据我所知，对于我们在 CS 中处理的有限 spaces，这总是可以完成的。
这意味着我们可以将 N space 描述为例如S 列出（或集合）一些规则，而通过为每个规则分配一组适用的工作流，每个规则适用于某些 W 工作流。是的，如果我们有一些原本应该应用于某些奇怪的工作流和状态配置组合的糟糕规则，那么我们可以将它们拆分为多个规则，这样就可以保持可分离性。
当然，这可以概括，但我将跳过细节，因为它们无关紧要。
说到这里，有人可能会疑惑，这有什么意义。好吧，如果我们可以将 N 维 space（在我们的例子中 N 大约是 10K）拆分成独立的子 space，那么魔法就会发生，而不是按照 N = W *S 的顺序书写* R tests to cover the whole parameter space 我们只需要按照W + S + R tests的顺序写就可以覆盖整个参数space。 在我们的例子中，差异大约是 100X。
但这还不是全部。正如我们可以在集合或列表（取决于需要）的概念中描述 subspaces，这自然会把我们带到无用测试的概念。
等等，我刚刚是在说无用的测试吗？是的，我做到了。让我解释。一个典型的 TDD 范例是，如果代码失败，那么我们需要做的第一件事就是创建一个测试，它会发现那个错误。好吧，如果代码是由静态列表或集合（== 列表或集合硬编码在代码中）描述的，并且测试将由来自 list/set 的身份转换来描述，那么这使得这样一个测试无用，因为它必须重复原来的 list/set…
状态配置形成了一种历史模式，例如，我们在 2018 年的某个时候对 CA 的状态制定了一些规则集。这组规则可能会在2019 年和 2020 年的一些规则。这些变化很小：一组规则可能会增加或丢失一些规则 and/or 规则可能会稍微调整一下，例如如果我们将某个值与某个阈值进行比较，那么对于某些状态配置，该阈值的值可能会在某个时候更改。一旦规则或规则集发生变化，它就应该保持原样，直到再次发生变化。同时一些其他的规则可能会被改变，每一个这样的改变都需要引入我们所说的状态配置。因此，对于美国的每个州，我们都订购了这些州配置的集合（列表），并且对于每个州配置，我们都有一组规则。大多数规则不会改变，但其中一些规则会如所述偶尔发生变化。一种自然的 IOC 方法是使用 IOC 容器注册每个规则集合和每个状态配置的每个规则，例如Unity 使用状态配置的唯一“名称”和规则/集合名称的组合（我们实际上 运行 在工作流期间有多个规则集合），而每个规则已经有一个工作流集合，它应该是适用的。然后，当给定状态配置和给定工作流的代码 运行s 时，我们可以将集合从 Unity 中拉出。然后一个集合包含应为 运行 的规则的名称。然后将规则的名称与状态配置的名称结合起来，我们可以从 Unity 中提取实际规则，过滤集合以仅留下适用于给定工作流的规则，然后应用所有规则。 这里发生的是规则名称/集合名称形成一些封闭集，并且通过这种方式描述它们会大大受益。我们显然不想手动为每个状态配置注册每个规则/集合，因为那会很乏味且容易出错。所以我们使用所谓的“规范化器”。假设我们有一个通用规则——这是一个对所有状态配置都相同的规则。然后我们仅按名称注册它，规范器将“自动”为所有状态配置注册它。历史版本控制也是如此。一旦我们通过规则/集合名称+状态配置向 Unity 注册规则/集合，规范器将填补空白，直到我们在稍后的某个状态配置更改规则。
这样一来，每一条规则都变得极其简单。他们中的大多数有零个或一个注入的构造函数参数，其中一些有两个，而且我只知道一个规则有三个注入参数。由于规则是独立的，非常简单，规则的测试也变得非常简单。
我们确实有一些想法可以让我在上面写的任何东西的核心开源，只要它能为社区带来一些价值...