language-agnostic - 切换到 ORM

Question

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

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

Answer 1

我强烈建议您获取一份 Michael Feather 的《有效地使用遗留代码》一书的副本（“遗留代码”羽毛是指单元测试未充分涵盖的任何系统）。它充满了很好的想法，可以帮助您重构和逐步采用最佳实践。

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

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

编辑：更正作者姓名

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

重构的规则是。做单元测试。

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

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

Answer 5

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

Answer 6

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

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

Answer 7

除非您的代码已经构建为允许模型层后端的“热交换”，否则以任何方式更改它总是非常危险的。

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

所以，除非你有一个强有力的商业案例来承担所涉及的风险，否则最好不要管它。