我正在尝试将ORM逐步引入我支持的应用程序中。该应用程序的结构不完善，没有任何单元测试。因此，任何更改都是有风险的。我显然很担心自己有足够的理由去改变。这样做的想法是减少用于数据访问的样板代码，从而提高生产率。

这与经历相符吗？
逐步实施它是否可能甚至是个好主意？
ORM的缺点是什么？

解决方案

回答

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

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

ORM应该设计为减少样板代码。进入企业的时间/麻烦与投资回报率由我们自己估算：)

回答

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

回答

我强烈建议我们获得一份迈克尔·费瑟(Michael Feather)的著作，《有效地使用旧版代码》("旧版代码"代表所有单元测试未充分涵盖的系统)。它充满了好主意，应该可以重构和逐步采用最佳实践。

当然，我们可以逐步引入ORM，首先使用它来访问域模型的某些子集。是的，我发现使用ORM可以加快开发时间，这是关键优势之一，而且我当然不会错过曾经费力地手工制作数据访问层的日子。

从经验出发，ORM的缺点是，要掌握所选ORM解决方案的概念，配置和特质，不可避免地会有一些学习曲线。

编辑：更正了作者的名字

回答

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

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

回答

除非代码已被架构化以允许模型层后端的"热交换"，否则以任何方式进行更改始终将具有极大的风险。

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

因此，除非我们有充分的商业理由承担所涉及的风险，否则最好还是保持足够的孤独。

回答

我在一个大型ASP.net应用程序上工作，我们最近开始在其中使用NHibernate。我们将一直手动保留的大量域对象移到了Sql Server上，而又移到了NHibernate上。它大大简化了事情，使随着时间的推移更改事情变得容易得多。我们很高兴进行了更改，并在适当的地方使用了NHibernate来完成许多新工作。

回答

必须由迈克尔·费瑟斯(Michael Feathers)实际写成的"罗伯特·马丁(Robert C Martin)"书(如今看来，"鲍伯叔叔"已经是一个商标！)。

更不用说将单元测试放入未使用它们开发的应用程序中的疯狂耗时了。该代码只是不适合。

但这不是问题。重构是指在不更改功能的情况下更改设计(我希望这里的含义没有受到太大的破坏)，因此我们可以以更广泛的方式工作。

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

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

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