通过这种方式，我编写此代码是可测试的，但是我缺少它吗？

我有一个名为的界面IContext。出于此目的，除了以下内容外，它的作用并不重要：

T GetService<T>();

该方法的作用是查看应用程序的当前DI容器，并尝试解决依赖关系。我认为还算标准。

在我的ASP.NET MVC应用程序中，我的构造函数如下所示。

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetService<ISomeService>();
    AnotherService = ctx.GetService<IAnotherService>();
}

因此，我不是在为每个服务的构造函数中添加多个参数（因为这对于扩展应用程序的开发人员来说确实很烦人和耗时），而是使用此方法来获取服务。

现在，感觉不对。但是，我目前在脑海中证明它的方式是这样- 我可以嘲笑它。

我可以。模拟IContext测试控制器并不难。无论如何，我必须：

public class MyMockContext : IContext
{
    public T GetService<T>()
    {
        if (typeof(T) == typeof(ISomeService))
        {
            // return another mock, or concrete etc etc
        }

        // etc etc
    }
}

但是正如我所说，这感觉很不对劲。任何想法/虐待。

在构造函数中使用一个参数代替许多参数不是该设计的问题部分。只要您的IContext类不过是服务门面（专门用于提供在中使用的依赖项）MyControllerBase，而不是整个代码中使用的常规服务定位符，那部分代码就可以了。

您的第一个示例可能会更改为

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetSomeService();
    AnotherService = ctx.GetAnotherService();
}

那不会是重大的设计变更MyControllerBase。这种设计的好坏仅取决于您是否愿意

• 确保TheContext，SomeService并且AnotherService始终都带有模拟对象的初始化，否则它们都与真实的物体
• 或者，允许使用3个对象的不同组合对其进行初始化（这意味着，在这种情况下，您需要分别传递参数）

因此，在构造函数中仅使用一个参数而不是3是完全合理的。

这是问题的关键是IContext露出GetService方法在公众面前。恕我直言，您应该避免这种情况，而应保持“工厂方法”的明确。那么可以使用服务定位器从我的示例中实现GetSomeService和GetAnotherService方法吗？恕我直言，这取决于。只要IContext类出于提供明确的服务对象列表的特定目的而保持简单的抽象工厂状态，恕我直言是可以接受的。抽象工厂通常只是“胶水”代码，本身无需进行单元测试。无论如何，您应该问自己是否在诸如之类的方法的上下文中GetSomeService，是否真的需要服务定位符，或者是否显式构造函数调用不会更简单。

因此要当心，当您坚持IContext只将实现作为公共通用GetService方法的包装的设计时，允许使用任意类来解决任意依赖关系，那么一切都会应用@BenjaminHodgson在其答案中所写的内容。

这种设计被称为服务定位器 *，我不喜欢它。有很多反对的说法：

服务定位器将您耦合到您的容器。使用常规的依赖项注入（构造函数在其中明确说明了依赖项），您可以直接将容器替换为其他容器，或者返回new-expressions。对于您而言IContext，这实际上是不可能的。

服务定位器隐藏依赖项。作为客户端，很难告诉您需要构造一个类的实例。您需要某种IContext，但还需要设置上下文以返回正确的对象以完成MyControllerBase工作。从构造函数的签名来看，这一点都不明显。使用常规DI，编译器会准确告诉您所需的内容。如果您的课程有很多依赖关系，您会感到痛苦，因为这会刺激您进行重构。服务定位器隐藏了设计不良的问题。

服务定位器会导致运行时错误。如果GetService使用错误的类型参数进行调用，则会出现异常。换句话说，您的GetService功能不是全部功能。（总功能是FP界的一个主意，但是从根本上讲，功能应该始终返回一个值。）最好让编译器提供帮助，并在出现依赖项错误时告诉您。

服务定位器违反了Liskov替换原则。由于其行为根据类型参数的不同而不同，因此可以将Service Locator视为在接口上实际上具有无限数量的方法！这个论点在这里详细说明。

服务定位器很难测试。您已经给出了一个IContext用于测试的伪造示例，这很好，但是当然最好不要一开始就编写该代码。只需直接注入伪造的依赖项，而无需通过服务定位器。

简而言之，就是不要这样做。对于具有很多依赖的类问题，这似乎是一种诱人的解决方案，但是从长远来看，这只会使您的生活痛苦不堪。

_{*我正在使用通用Resolve<T>方法将Service Locator定义为一个对象，该方法能够解决任意依赖关系，并且在整个代码库中使用（不仅在Composition Root中）。这与Service Facade（捆绑一些已知的少量依赖项的对象）或Abstract Factory（创建单一类型实例的对象- 抽象工厂的类型可能是通用的，但方法不同）不同。 。}

马克·西曼（Mark Seemann）明确指出了反对Service Locator反模式的最佳论据，因此我不会过多地解释为什么这是一个坏主意-这是一个学习过程，您必须花时间自己理解（我还推荐Mark的书）。

好了，请回答这个问题-让我们重新陈述您的实际问题：

因此，我不是在为每个服务的构造函数中添加多个参数（因为这对于扩展应用程序的开发人员而言确实很烦人和耗时），而是使用此方法来获取服务。

在StackOverflow上有一个解决此问题的问题。如其中一项评论所述：

最好的一句话是：“构造函数注入的奇妙好处之一是，它使违反单一责任原则的行为显而易见。”

您在错误的位置寻找解决方案。重要的是要知道什么时候上课做得太多。在您的情况下，我强烈怀疑不需要“基本控制器”。实际上，在OOP中，几乎几乎根本不需要继承。行为和共享功能的变化可以完全通过适当使用接口来实现，这通常会导致代码分解和封装更好-无需将依赖项传递给超类构造函数。

在我研究过的所有存在基础控制器的项目中，它的完成纯粹是为了共享方便的属性和方法，例如IsUserLoggedIn()和GetCurrentUserId()。停止。这是对继承的可怕滥用。相反，创建一个公开这些方法的组件，并在需要时对其进行依赖。这样，您的组件将保持可测试性，并且它们之间的依赖关系将显而易见。

除了其他方面，当使用MVC模式时，我总是会建议使用瘦控制器。您可以在此处阅读有关此内容的更多信息，但该模式的本质很简单，即MVC中的控制器应该只做一件事：处理MVC框架传递的参数，将其他问题委托给其他组件。这也是工作中的单一责任原则。

知道您的用例做出更准确的判断确实会有所帮助，但是老实说，我无法想到任何情况下基类胜于精心构造的依赖关系。

我要根据其他人的贡献为此添加一个答案。非常感谢大家。首先，这是我的回答：“不，这没什么问题”。

Doc Brown的“ Service Facade”答案 我接受了此答案，因为我正在寻找的（如果答案为“否”）是一些示例或对我正在做的事情的扩展。他提供此信息的目的是建议A）有一个名字，B）可能有更好的方法来做到这一点。

本杰明·霍奇森（Benjamin Hodgson）的“服务定位器”答案 尽管我很欣赏在这里获得的知识，但我所拥有的并不是“服务定位器”。这是一个“服务外观”。此答案中的所有内容都是正确的，但不适用于我的情况。

USR的答案

我将更详细地解决这个问题：

您正在以这种方式放弃很多静态信息。您像许多动态语言一样将决策推迟到运行时。这样，您将失去静态验证（安全性），文档和工具支持（自动完成，重构，查找用法，数据流）。

我不会丢失任何工具，也不会丢失任何“静态”类型。服务外观将返回我在DI容器或中配置的内容default(T)。它返回的是“类型化”。反射被封装。

我不明白为什么添加额外的服务作为构造函数参数会带来很大的负担。

当然不是“稀有”。当我使用基本控制器时，每次需要更改其构造函数时，我可能都必须更改10、100、1000个其他控制器。

如果您使用依赖项注入框架，则甚至不必手动传递参数值。然后，您又失去了一些静态优势，但没有那么多。

我正在使用依赖注入。这才是重点。

最后，朱尔斯对本杰明回答的评论 我没有失去任何灵活性。这是我的服务门面。我可以添加多个参数以GetService<T>区分不同的实现，就像配置DI容器时所做的一样。因此，例如，我可以更改GetService<T>()为GetService<T>(string extraInfo = null)来解决此“潜在问题”。

无论如何，再次感谢大家。这真的很有用。干杯。