切换到 ORM答案

【问题标题】：Switching to ORMs切换到 ORM
【发布时间】：2008-08-22 10:05:44
【问题描述】：

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

您的经历是否属实？
是否可以分阶段实施，甚至是一个好主意？
ORM 的缺点是什么？

【问题讨论】：

【解决方案1】：

我强烈建议您获取一份 Michael Feather 的书 Working Effectively With Legacy Code 的副本（“遗留代码”Feathers 是指任何未被单元测试充分覆盖的系统）。它充满了很好的想法，可以帮助您重构和逐步采用最佳实践。

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

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

编辑：更正作者姓名

【讨论】：

【解决方案2】：

“罗伯特·C·马丁”这本书实际上是由 Michael Feathers 写的（“鲍勃叔叔”现在似乎是一个品牌名称！）是必须的。

几乎不可能 - 更不用说非常耗时 - 将单元测试放入不是用它们开发的应用程序中。代码只是不适合。

但这不是问题。重构是在不改变功能的情况下改变设计（我希望我没有严重破坏其中的含义），因此您可以以更广泛的方式工作。

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

现在你可以开始重构了。您想开始提取您的数据访问代码，以便可以用 ORM 功能替换它而不会造成太多干扰。经常测试：使用旧版应用程序，您会惊讶于出现什么问题；内聚和耦合很少是它们可能的样子。

我还会考虑查看 Martin Fowler 的 Refactoring，这显然是该过程的权威工作。

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

除此之外，ORM 是一个不错的选择，绝对应该考虑。

【讨论】：

【解决方案6】：

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

所以也许首先你应该至少为核心/主要的事情放置一些单元测试。

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

【讨论】：

【解决方案7】：

除非您的代码已经构建为允许对模型层后端进行“热交换”，否则以任何方式对其进行更改都将带来极大的风险。

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

因此，除非您有一个强有力的商业理由来承担所涉及的风险，否则最好不要管它。

【讨论】：