流浪数据与可测试性答案

【问题标题】：Tramp Data vs. Testability流浪数据与可测试性
【发布时间】：2011-03-31 05:30:30
【问题描述】：

我现在没有做太多新的开发，而是对旧的 C# 子系统进行大量重构，这些子系统的原始要求不再支持新的，我将添加意想不到的要求。我现在也在尽可能使用 Rhino Mocks 和单元测试（与 2008 年相比）。

我的困境是，为了使方法可测试和可模拟，我需要使用接口定义清晰的“合同”。但是，如果我这样做，许多类使用的大量全局数据会变成流浪数据，从一个方法传递到另一个方法，直到它到达目标用户；这看起来很丑陋，并且违背了我的感受，但是……可以被嘲笑。制作具有大量静态全局属性的混合包类是一个更有吸引力的选择，但 Rhino 无法测试。两者之间有中间立场吗？可测试但不太笨拙？也许是模式？

您还应该了解，这些应用程序运行在公司内部开发的平台上，因此有很多帮助程序类和服务，每个应用程序实例化一次，然后在整个应用程序中使用，例如数据库访问器助手类。另一个例子是使用一次读取的配置文件，并出于各种原因通过不同的方法在整个应用程序中使用。

感谢您的想法。

【问题讨论】：

标签： c# design-patterns architecture refactoring rhino-mocks

【解决方案1】：

您可能想在这里查看某种形式的Service Locator Pattern。让他们的班级找到自己的流浪汉。

其他一些合理的选择包括将大部分常用的东西包装在某种“应用程序上下文”类中。

如果您还没有这样做，您可能还希望研究依赖注入。

【讨论】：

服务定位器应被视为anti-pattern。 OP 写道：“......我需要使用接口定义明确的“合同”。”服务定位器掩盖了合同，因为您看不到服务定位器实际上应该提供哪些接口。
@JørgenFogh——2016 年的公平点，2010 年的 .NET 情况并非如此。此外，它们仍然占有一席之地，尤其是在您移植未针对适当 DI 构建的遗留应用程序时。
也许——但不能作为流浪数据的替代品。