orm框架选型问题_ORM问题

最新推荐文章于 2024-07-02 16:56:35 发布

dnc8371

最新推荐文章于 2024-07-02 16:56:35 发布

阅读量427

点赞数

文章标签：数据库大数据编程语言 python java

原文链接：https://www.javacodegeeks.com/2011/09/problems-with-orms.html

版权

orm框架选型问题

在过去的几年中，像Hibernate这样的对象关系映射工具已经帮助开发人员在处理关系数据库方面获得了巨大的生产力增长。 ORM使开发人员可以专注于应用程序逻辑，并避免为诸如插入或查询之类的简单任务编写大量样板SQL。

但是，充分证明的对象关系阻抗不匹配问题不可避免地引起开发人员的头痛。关系数据库是建立在合理概念基础上的一种专门技术，但是它们不一定符合面向对象的世界。有几种使用ORM的方法和样式，它们各有利弊。

使用ORM的基本选择之一是确定是从数据库架构生成ORM映射，还是从数据库架构生成ORM定义（可能是XML配置文件，注释或类似XDoclet之类的数据库架构））。

从数据库架构生成ORM层的前一种方法意味着，无论是处理特定于数据库的DDL还是具有某些抽象层，都必须使用其自己的语言和术语来处理数据库，但是仍然不得不处理数据库本身。不幸的是，这意味着您需要技术方面的专业知识，并且可能要花费比允许生成架构更多的工作。但是，这迫使开发人员正确理解和处理RDBMS –将DBMS视为简单数据存储区既危险又有害。开发人员在设计应用程序时需要考虑键，索引等的影响，并将它们与关系数据库的现实掩盖起来可能很危险，而根据我的经验，这总是很糟糕的。一个相关的问题是POJO的使用，最终由ORM框架操纵。从理论上讲，这听起来不错，但实际上您会遇到各种各样的问题，并且很可能将应用程序逻辑与真正应该构成数据访问对象的逻辑混合在一起。开发人员和架构师喜欢通过使用Spring和其他框架来赞扬关注点的分离，并且没有真正的理由为什么不应在此处应用相同的概念。另一个较小的问题是需要维护POJO和映射定义，但这通常不是太多的工作。

从您的模式生成ORM映射和代码的第二种方法是我的首选方法。根据我使用这两种方法的经验，可以从模式中生成bean，从而可以智能地设计bean，并且仅根据需要使其变得复杂，同时可以免费按PK，按索引等进行获取。由于它们都在持久性类本身中进行管理，因此管理惰性集合和引用对象之类的事情也变得更加容易。这种方法还避免了编写样板POJO的需要，并迫使您将数据访问对象与域对象和业务逻辑分开对待。根据我从架构生成数据访问bean的经验，这些bean最终变得更丰富，更可用，性能更好，并且一旦建立了基础架构，维护成本就会降低。有人可能会认为您最终需要其他数据包装器类，但实际上，对单独的Bean类的需求与数据访问层中发生的情况无关。这里的一个问题是可以为您完成这一代工作的框架的可用性–过去，我曾使用过定制的解决方案，这些解决方案虽然效果很好并取得了回报，但是需要初期的前期工作。在较小的项目上，可能没有足够的回报值得在这种工作上进行投资。同时，有一些采用这种方法并生成持久性实体类的ORM ，例如jooq ，但是我必须尝试一下。

Hibernate是Java领域中最流行的ORM，尽管它与处理大量SQL无关，但它存在一些问题。通常，该方法是定义映射和POJO，然后让Hibernate管理SQL生成。这样做的问题是您定义的架构通常不理想，并且最终忽略了诸如正确索引之类的事情。尽管您选择使用其专有内容的程度由您决定，但Hibernate还会迫使您最终使用其事务和查询机制。这不一定在所有情况下都是一件坏事，但是我个人对经常使用的HQL语言感到不满意，因为它为开发人员引入了一种熟悉的，不同的语言，其他人后来不得不维护并尝试弄清楚出来。查询优化也可能出现问题，并且过去在性能调优方面做了大量工作，对我来说，必须访问实际查询以进行调优。我还认为，尝试在持久性类中实现继承只是一个坏主意–试图将一个概念强加到自然无法容纳它的技术上是不值得的。 Hibernate诱使开发人员通过支持按层次结构表和按类的机制在数据库中实现继承，但这在我心中是一个错误，因为您最终会遇到不良的数据模型以及以后管理和扩展层次结构的问题。我也不喜欢填充应该是干净的关系模型-您不能假装关系数据库是面向对象的数据存储。

如果您从这篇文章中删除了一件事，那就应该是不要忽略您正在使用的实际技术。对待RDBMS到底是什么，然后学习使用它。对面向对象的系统执行相同的操作。无论如何，请尝试通过使用ORM来避免编写样板代码和不必要SQL，从而使您的生活更轻松，但是不要认为您可以避免处理某种翻译或代码来应对自然发生的不匹配。不要期望使用框架或工具来为您解决问题。开发人员付钱去思考和辨别最好的道路，因此我们不应该害怕在问题出现时以明智的方式处理它们。与许多事物一样，此处适用80-20规则。使用ORM可以为您完成80％的工作，并准备为另外20％的工作编写SQL和一些持久性代码。不要期望太高，否则您最终会遇到几种类型的问题-奇怪的错误，性能问题，设计不良的面向对象模型等。

我很想听听您对任何语言的ORM的经验和想法以及您所面临的问题，以及如何处理它们。这是经验非常宝贵的主题之一，因此请分享您的想法。

参考： 问题与奥姆斯我们JCG伙伴 ■在Carfey软件博客。

相关文章：