更换系统性物体的策略

Question

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

因为应用程序没有使用数据抽象层构建，所以在应用程序的每个层中都有ADO调用，以至于划分任何一个对象并尝试将其转换为Linq意味着您沿着迷宫运行兔子洞。

我要问的是，在确保适当的测试和最小的“掉落工具”放假期间（处理器制作时会发生变化并在以后再次发布）时，需要采取措施来处理批发系统性变更）。

我们玩弄了以下内容：

• 使用新代码创建每个对象的镜像对象=必须维护2个代码库，直到完全转换
• 使用ADO_前缀ADO函数的所有函数名称，并使用原始名称
创建Linq版本
• 使用系统范围的FLAG来表示是否使用ADO或Linq并使用if（FLAG）{ADO}来包装每个ADO调用其他{Linq} =必须在转换后返回并删除所有ADO refs

到目前为止，每一个建议都是值得的。

你们/ gals建议你做什么？

注意：我从标题中删除了'（ADO to Link）'，因为我正在寻找更多通用的答案和做法，而不仅仅局限于此处使用的ADO到Linq转换。

Answer 1

在进行任何更改之前，您应该进行自动单元测试。实际上，您不应对单元测试未涵盖的代码进行至少80％的更改。

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

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

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

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

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

Answer 2

您仍然可以利用最初为Linq2SQL解决方案创建的所有存储过程/函数。使用Micheal Feather Working with Legacy Code中表达的策略，您可以在应用程序的各个区域创建边界，并在这些边界内进行更新。

我过去使用的策略是维护/忽略数据库及其对象。然后我慢慢地遍历不同的ADO调用并替换为Linq2SQL调用，直到整个应用程序使用Linq2SQL。然后，我发现更容易将先前暴露并传递给DataSets / DataTables的ADO调用转换为更合适的实体。

另一种方法（对于DataSet / DataTable重型解决方案）是保持ADO调用，而是使用扩展方法AsQueryable()和/或OfType<T>()将ds / dt项转换为适当的实体，然后将这些变化汇总成更具凝聚力的DAL。