问ORM是否会对OO设计产生反作用？

EN

在好的数据库设计的需求和好的OO设计的需求之间有一个众所周知且经常被忽略的阻抗不匹配。大多数开发人员(以我的经验)要么不理解这种阻抗不匹配，要么不关心。由于更常见的方式是从数据库开始并从数据库生成对象(而不是相反)，那么是的，您最终得到的对象作为持久层很棒，但从面向对象的角度来看并不是最优的。(相反，从对象模型生成数据库，会让我想把眼睛戳出来。)

从面向对象的角度来看，为什么它们是次优的？因为ORM产生的对象不是业务对象，即使具有分部类等。业务对象对行为进行建模。ORM对象为持久化建模。我不打算花十个段落来论证这一区别。这是Rocky Lhotka在他的关于业务对象和他的CSLA framework的书中很好地讨论的东西。无论您是否喜欢或不使用CSLA，我认为他的论点都是可靠的。

如果对象不再以行为为特征，在我看来，这将使对象的身份和责任变得混乱。

所讨论的对象确实具有按照定义的行为读取和写入数据库。除此之外，他们没有太多其他的东西。

实际情况很简单:面向对象本身并不是目的，它只是达到目的的一种手段--但在某些情况下，它并不能很好地改善最终结果。ORM的许多用途就是一个很好的例子--它们是CRUD应用程序的数千种变体，它们不需要或不想将任何实际行为附加到它们处理的大多数数据上。

作为一个整体，应用程序通过不将大量(如果有的话)数据“行为”编码到应用程序本身的代码中来获得灵活性。取而代之的是，它们通常更适合作为“哑巴”数据，它们只是简单地从UI传递到数据库，然后返回到报告等。稍加注意，这可以允许相当程度的用户自定义，而当您尝试将数据视为具有实际行为编码到应用程序中的真实对象时，这几乎是不可能匹配的。

当然，这也有另一面:这可能会使确保数据的完整性或仅适当使用数据变得更加困难--我曾见过在计算中意外使用错误字段的代码，因此他们平均计算办公室数量，而不是以平方英尺为单位的办公室面积。这两个都是用户定义的字段，只是说明内容应该是数字。应用程序无法知道其中一个是完全有意义的，而另一个则完全没有意义。

案例和要点:许多OR/M工具都带有point-to-a-database-table-and-click-object-generator.

是的，但是有相同的，如果不是更大的数字或ORM解决方案，它们基于您的对象并生成您的数据库表。

如果你从数据开始，然后迫使自动生成的对象具有对象行为，是的，你可能会感到困惑……但是，如果您从对象开始，并将数据库作为第二层生成，那么您最终会得到一些更有用的东西，即使数据库可能没有得到最大程度的优化。

如果你正在寻找不使用ORM的借口，那就不要使用它。我个人发现，它为我节省了数千行代码，做了ORM做得非常好的琐碎事情。