替换系统对象的策略
我们目前正着手用Linq替换ADO.NET应用程序中的C#堆栈。
由于应用程序不是用数据抽象层构建的，所以在应用程序的几乎每一层都有ADO调用，以至于将任何一个对象划分开来并试图将其转换为Linq意味着您沿着兔子洞的迷宫运行。
我要问的是，解决这种大规模系统性变化的州或方法，同时确保适当的测试和最小的“放下工具”的停摆期(货架在某一时刻进行更改，并在稍后的日期回来)。
我们玩了以下几个游戏：
创建每个对象的镜像对象，使用新代码=必须维护两个代码基，直到完整的conversion
- Prefix，所有带有ADO_的
- 函数名称，以及创建原来名称为
- 的ADO_版本，都有一个系统范围的标志来表示是否使用ADO或Linq，并将每个ADO调用包装为if (标志){
- }{ Linq }=必须在转换后返回并删除所有ADO refs
。
到目前为止，每一个建议都是值得的。
你们俩/女孩有什么建议？
注意:我从标题中删除了'(ADO到Linq )‘，因为我正在寻找更通用的答案和实践，而不仅仅局限于这里用作示例的ADO到Linq的转换。
回答 2
Stack Overflow用户
发布于 2010-02-24 15:17:19
在进行任何更改之前，您确实应该进行自动化的单元测试。实际上，您不应该对单元测试不包含的代码进行至少80%的更改。
在现实世界中，单元测试通常不存在。另一方面，在没有单元测试的情况下进行任何重构都会完全破坏您的代码，使Management更不可能允许您在将来进行更改。该怎么办呢？
使用像ReSharper这样的工具，您可以从应用一些“更安全”的重构开始。小心点，您没有理由不能成功地重复使用“提取方法”将您的ADO.NET代码移动到单独的方法中，如果方法不是静态的“让方法静态”，那么可以使用"Move Method“或"Make Method non-静态”将方法移动到一个单独的类中。
一旦代码移出，您就可以开始编写一些自动化测试了。在这个阶段，他们不需要是严格意义上的“单元测试”。特别是，应该允许这些测试与数据库一起工作。
当您只剩下不容易进行单元测试的代码时，您就可以非常小心地开始使该代码更易于测试。您可以将静态方法的集合转换为新类的实例方法。您还可以开始引入依赖项注入，以便更容易地使用模拟对象进行测试。但是这里要非常小心--您正在修改没有自动测试的代码，而且您将使用重构，这些重构实际上会破坏一些内容。
一旦对代码进行了充分的测试，那么您就可以重新组织代码，使其更有意义，然后修改它，使其使用LINQ (如果您愿意)。
Stack Overflow用户
发布于 2010-02-18 10:19:47
您仍然可以利用最初为Linq2SQL解决方案创建的所有存储过程/函数。使用类似于迈克尔·费瑟的Working with Legacy Code中所表达的策略，您可以在应用程序的区域周围创建边界，并在这些边界内进行更新。
我过去使用的策略是维护/忽略数据库及其对象。然后，我慢慢地遍历不同的ADO调用，然后用Linq2SQL调用替换，直到整个应用程序都使用Linq2SQL。然后，我发现更容易将以前公开并传递数据集/DataTable的ADO调用转换为更合适的实体。
另一种方法(对于DataSet/DataTable重型解决方案)是保持ADO调用到位，而是使用扩展方法AsQueryable()和/或OfType<T>()将ds/dt项转换为适当的实体，然后将这些更改聚合到一个更有凝聚力的DAL中。
https://stackoverflow.com/questions/2277056
复制
腾讯云开发者
