我正在考虑将ORM逐步引入我支持的应用程序中。该应用程序结构不完整，没有单元测试。所以任何改变都是有风险的。我显然担心我有足够的理由改变。我们的想法是，用于数据访问的锅炉板代码将更少，并且可以提高生产率。
根据您的经验，这是否真实？ 是否可能或甚至是一个好主意进行分阶段？ ORM的缺点是什么？
答案 0 :(得分：3)
我强烈建议您获取Michael Feather的书Working Effectively With Legacy Code的副本（“Legacy Code”Feathers表示任何单元测试未充分涵盖的系统）。它充满了好的想法，可以帮助您重构和逐步采用最佳实践。
当然，您可以逐步引入ORM，最初使用它来访问您的域模型的某个子集。是的，我发现使用ORM可以加快开发时间 - 这是关键的好处之一，我当然不会错过我曾经费力地手工制作数据访问层的日子。
ORM的缺点 - 根据经验，在掌握所选ORM解决方案的概念，配置和特性方面，不可避免地需要学习一些学习曲线。
编辑：更正作者姓名
答案 1 :(得分：2)
“罗伯特·C·马丁”这本书实际上是迈克尔·费尔斯（Michael Feathers）写的（“叔叔鲍勃”，现在似乎是一个品牌名称！）是必须的。
将单元测试放入不是用它们开发的应用程序中几乎是不可能的 - 更不用说非常耗费时间了。代码不适合。
但这不是问题。重构是关于在不改变功能的情况下改变设计（我希望我没有在那里太糟糕地破坏它的含义）所以你可以以更广泛的方式工作。
从大块开始。设置可重复执行，并捕获后续执行的预期结果。现在，您的应用程序或至少部分应用程序正在测试中。当然，这不是一个非常好或全面的测试，但这是一个开始，事情只会从那里变得更好。
现在你可以开始重构了。您希望开始提取数据访问代码，以便可以使用ORM功能替换它而不会打扰太多。经常测试：使用传统应用程序，你会惊讶于什么打破;凝聚力和耦合很少是它们的本质。
我也会考虑看看Martin Fowler的Refactoring，这显然是关于这个过程的最终工作。
答案 2 :(得分：1)
我在一个大型ASP.net应用程序上工作，我们最近开始使用NHibernate。我们将手动持久化的大量域对象移动到Sql Server而不是NHibernate。它简化了一些事情，并且随着时间的推移更容易改变。我们很高兴我们进行了更改，并在适当的时候使用NHibernate来完成我们的许多新工作。
答案 3 :(得分：0)
重构规则是。做单元测试。
所以，首先你应该至少为核心/主要事物放置一些单元测试。
ORM应设计用于减少样板代码。时间/问题与投资回报率的关系由您来估算：）
答案 4 :(得分：0)
我听说TypeMock经常用于重构遗留代码。
答案 5 :(得分：0)
我认真地认为将ORM引入遗留应用程序是在寻找麻烦（并且可能与完全重写相同的麻烦）。
除此之外，ORM是一个很好的方式，绝对应该考虑。
答案 6 :(得分：0)
除非您的代码已经架构为允许模型层后端的“热交换”，否则以任何方式更改它将始终存在极大的风险。
尝试在架构不佳的代码上构建单元测试的安全网并不能保证成功，只会让您感觉更安全。
因此，除非你有一个强大的商业案例来承担所涉及的风险，否则最好不要单独留下。