orm查询部分字段_ORM问题第2部分

orm查询部分字段_ORM问题第2部分–查询

orm查询部分字段

在我以前关于对象关系映射工具（ORM）的帖子中，我讨论了在处理当今常见的ORM（包括Hibernate）时遇到的各种问题。其中包括与从POJO生成架构有关的问题，实际性能和不断出现的维护问题。本质上，结论是ORM可以为您提供大部分帮助，但是需要一种平衡的方法，有时您只是想避免使用ORM的工具集，因此您应该能够在需要时绕过它。

我看到的现代ORM的一个巨大缺陷是，它们确实希望帮助您解决所有SQL问题。我这是什么意思，为什么我要说这是一个错误？好吧，我相信Hibernate等人只是太努力了 ，最终提供的功能实际上给开发人员带来的伤害超过了他们的帮助。我所说的主要思想是查询支持。 ORM中严重缺乏对易于维护的复杂查询的实际支持，并不是因为它们省略了一些东西-仅仅是因为它们提供的工具没有使用SQL，SQL正是为此目的而专门设计的。

Hibernate的经验

我的经验是，当您使用HQL之类的功能时，经常会考虑将自己节省几分钟，这本身并没有什么问题，但这会引起严重的问题。根据我的经验，由于错误修复或增强功能，您最终常常想要或需要用更灵活的方式替换HQL，而这正是麻烦的开始。

我认为自己是一位经验丰富的开发人员，并且我为自己（通常）不打破事物而感到自豪-对我而言，这是优秀开发人员的标志之一。当您面临着剥离一段代码并大范围地替换它（例如用SQL替换HQL）时，您基本上是在替换具有悠久历史的代码，这些历史记录包括错误修复，增强功能和性能调整。现在，您有责任复制对此代码的所有更改，并且很可能您不了解更改的全部范围或过去已纠正的小问题。

请注意，这也适用于Hibernate提供的所有其他查询方法，包括Query API，以及扩展到JPA中的查询支持。问题是您不希望解决方案过于脆弱或受限，因此以后必须完全替换。这意味着，如果您需要恢复为SQL以完成任务，则很有可能首先应该这样做。相同的概念适用于软件开发的所有领域。
因此，如果像Hibernate这样的ORM中的基本查询支持不够好，我们的目标是什么？

坚实的ORM的标准

基本上，我对ORM的个人要求可以归结为以下几点：

架构优先–从数据库生成模型，而不是相反。如果您有与平台无关的为数据库指定DDL的方式，那很好，但这不是一个大问题。从其他某些特定于域的语言或格式生成数据库不会帮助任何人，并且会导致设计不良的架构。
仅限于SQL –如果您想帮助我避免编写代码，然后为我生成/公开基于密钥的查询等。不要要求我使用您的查询API或某些新的查询语言。 SQL是为查询而发明的，所以让我使用正确的工具。
给我简单的方法来从查询中填充域对象。这给了我99％的需求，同时又给了我灵活性。
请允许我用查询结果填充任意Java Bean –不要将我绑定到已知类型的注册表中。
不要强迫我使用像Hibernate或Spring提供的那样的典型事务容器–它们是一场灾难，而且我从未见过对它们有意义的实际用途。让我来处理在我的应用程序中获取和释放连接/事务的位置–通常，这仅发生在少数几个具有清晰语义的地方。这可以是JDBC的某些抽象版本，但让我控制它。
我的域对象中没有聪明/神奇的行为–使用Hibernate时，我花了很多时间解决相同的旧代理和延迟加载问题。它们永无止境，无法一劳永逸地解决，这表明存在严重的设计问题。

尽管这些观点对我来说似乎是完全合理的，但我还没有遇到任何真正能够满足我期望的ORM，因此在Carfey，我们推出了自己的小ORM，我不得不说，周末的项目以及我们所拥有的只是总体发展比Hibernate或我使用的其他ORM更加容易和快捷。它提供什么？

一个简单的功利主义ORM

Java域类是从数据库模式生成的。尚无平台无关的DDL，但它在我们的TODO列表中。 Bean包括对子集合，FK引用的支持，但是它们都是惰性的和可选的– Bean支持它，但是，如果您不使用它们，则不会产生影响。如果需要，可以直接使用ID，也可以使用域对象本身。持久性仅处理持久性脏对象，并且仅在请求时才进行保存-没有魔术冲洗行为。
生成的域类仅用于持久性！将您的业务逻辑等置于其他位置。
SQL用于所有查找，包括主键提取和外键关系。如果您需要增强查找，只需窃取生成SQL并在其上进行构建即可。方法和SQL是从任何索引列中自动生成的，因此会自动为您提供它们并且类型安全。这也向开发人员发出警告–如果您的域类中没有可用的查找，则由于索引不存在，查找性能可能会变差。
可以以类型安全的方式从自定义查询中填充任何域类-灵活但易于使用。
改进的类可隐藏标准的JDBC类型（例如Connnection和Statement ，以便于使用，但我们不会对您施加任何事务语义，并且您始终可以退回到直接结果集处理之类的方法。
一些基本的必需功能，例如连接池，数据库元数据以及很快的数据库从属故障转移。

Carfey的我们不相信我们已经创建了一些令人难以置信的新ORM，超越了所有其他工作，如果这是一个公共项目，我们必须添加许多功能，但是我们所拥有的功能对我们有用，并且我认为我们有正确的方法。至少，希望我们的经验可以帮助您明智地选择使用首选的ORM，而不用花费太多时间来提供工具而不是交付软件。

最后要说明的是，如果您有满足我上面要求列表的ORM的经验，并且您有很好的经验，那么我很乐意听到有关它的信息，并考虑将其用于将来的Carfey项目。

参考： ORM的问题第2部分–来自我们JCG合作伙伴的查询 Carfey软件博客上的 Craig Flichel。