切换到 ORM

Question

我正在考虑将 ORM 逐步引入我支持的应用程序中。该应用程序的结构不是很好，没有单元测试。所以任何改变都会有风险。显然我担心我是否有足够的理由去改变。这个想法是，用于数据访问的样板代码将会更少，从而提高生产力。

这与你的经历相符吗？
分阶段实施是否可能，甚至是个好主意？
ORM 的缺点是什么？

Answer 1

我强烈建议您买一本迈克尔·费瑟的书 有效地处理遗留代码 （“遗留代码”羽毛是指单元测试未充分覆盖的任何系统）。它充满了好主意，可以帮助您重构和逐步采用最佳实践。

当然，您可以分阶段引入 ORM，最初使用它来访问域模型的某些子集。是的，我发现使用 ORM 可以加快开发时间 - 这是主要好处之一，我当然不会怀念过去费力手工制作数据访问层的日子。

ORM 的缺点 - 根据经验，在掌握所选 ORM 解决方案的概念、配置和特性方面不可避免地存在一些学习曲线。

编辑：更正了作者姓名

Answer 2

《罗伯特·C·马丁》一书实际上是由迈克尔·费瑟斯（Michael Feathers）撰写的（“鲍勃叔叔”现在似乎是一个品牌名称！），这是必须的。

将单元测试放入非使用单元测试开发的应用程序中几乎是不可能的，更不用说极其耗时。该代码不适合。

但这不是问题。重构是指在不改变功能的情况下改变设计（我希望我没有太严重地破坏了其含义），这样你就可以以更广泛的方式工作。

从大块开始。设置可重复的执行，并捕获发生的情况作为后续执行的预期结果。现在您的应用程序或至少是其中的一部分正在接受测试。当然，这不是一个非常好的或全面的测试，但这是一个开始，事情只会变得更好。

现在你可以开始重构了。您想要开始提取数据访问代码，以便可以用 ORM 功能替换它，而不会造成太多干扰。经常测试：对于旧版应用程序，您会惊讶地发现什么问题；内聚力和耦合度很少达到应有的水平。

我还考虑看看 Martin Fowler 的 重构, ，显然，这是该过程的决定性工作。

Answer 3

我负责一个大型 ASP.net 应用程序，我们最近开始使用 NHibernate。我们将大量手动保存到 Sql Server 的域对象移至 NHibernate。它大大简化了事情，并且随着时间的推移更容易改变事情。我们很高兴做出了这些改变，并在适合我们许多新工作的地方使用 NHibernate。

Answer 4

我听说 TypeMock 经常被用来重构遗留代码。

Answer 5

我认真地认为将 ORM 引入遗留应用程序会带来麻烦（并且可能与完全重写带来同样多的麻烦）。

除此之外，ORM 是一个很好的方法，绝对应该考虑。

Answer 6

重构的规则是。进行单元测试。

因此，也许首先您应该至少对核心/主要内容进行一些单元测试。

ORM 的设计应该是为了减少样板代码。时间/麻烦 vs企业的投资回报率由您来估计:)

Answer 7

除非您的代码的架构已经允许模型层后端“热交换”，否则以任何方式更改它都将始终存在极大的风险。

尝试在架构不佳的代码上构建单元测试的安全网并不能保证成功，只会让您对更改它感到更安全。

因此，除非您有充分的商业理由来承担所涉及的风险，否则最好不要干涉。