更换系统性物体的策略

Question

我们目前正着手用Linq替换C#应用程序中的ADO.NET堆栈.

因为应用程序没有使用数据抽象层构建,所以在整个应用程序的每一层都有ADO调用,以至于划分任何一个对象并尝试将其转换为Linq意味着你跑下了一个迷宫般的兔子洞.

我所要求的是处理这种批发系统变化的政策或方法,同时确保适当的测试和最小的"掉落工具"结束时间(货架在瞬间发出变化并在以后再回来).

我们玩弄了以下内容:

到目前为止,每一个建议都是令人畏缩的.

你们/ gals建议你做什么？

注意:我从标题中删除了'(ADO to Link)',因为我正在寻找更通用的答案和实践,而不仅仅局限于此处使用的ADO到Linq转换.

Answer 1

在进行任何更改之前，您确实应该进行自动化单元测试。事实上，对于至少 80% 未被单元测试覆盖的代码，您不应该进行任何更改。

在现实世界中，单元测试通常不存在。另一方面，在没有单元测试的情况下进行任何重构可能会完全搞砸您的代码，使管理层更不可能允许您将来进行更改。该怎么办？

使用 ReSharper 这样的工具，您可以首先应用一些“更安全”的重构。小心地，您没有理由不能成功地重复使用“提取方法”将 ADO.NET 代码移动到单独的方法中，如果它还不是静态的，则“使方法静态”，然后“移动方法”或“使方法非静态”将方法移至单独的类中。

一旦您将代码移出，您就可以开始编写一些自动化测试。在这个阶段，它们不需要是严格意义上的“单元测试”。特别是，应该允许这些测试与数据库一起工作。

当您只剩下不容易进行单元测试的代码时，您可以非常小心地开始使该代码更具可测试性。您可以执行诸如将静态方法集转换为新类的实例方法之类的操作。您还可以开始引入依赖项注入，以便更轻松地使用模拟对象进行测试。但这里要非常小心 - 您正在修改没有自动化测试的代码，并且您将使用实际上可能会破坏内容的重构。

一旦对代码进行了充分的测试，您就可以重新组织代码以使其更有意义，然后根据需要对其进行修改以使其使用 LINQ。