网站建设功能模块几报价,企业网站开发实训心得,做网站需要花钱吗,seo免费优化网址软件在我以前关于对象关系映射工具#xff08;ORM#xff09;的帖子中#xff0c;我讨论了在处理当今常见的ORM#xff08;包括Hibernate#xff09;时遇到的各种问题。 其中包括与从POJO生成架构有关的问题#xff0c;实际性能和不断出现的维护问题。 本质上#xff0c;结论… 在我以前关于对象关系映射工具ORM的帖子中我讨论了在处理当今常见的ORM包括Hibernate时遇到的各种问题。 其中包括与从POJO生成架构有关的问题实际性能和不断出现的维护问题。 本质上结论是ORM可以为您提供大部分帮助但是需要一种平衡的方法有时您只想避免使用ORM的工具集因此您应该能够在需要时绕过它。 我看到的现代ORM的一个巨大缺陷是它们确实希望帮助您解决所有SQL问题。 我是什么意思为什么我要说这是一个错误 好吧我相信Hibernate等人只是太努力了 最终提供的功能实际上对开发人员的伤害大于对他们的帮助。 我所说的主要思想是查询支持。 ORM中严重缺乏对易于维护的复杂查询的实际支持并不是因为它们省略了一些东西而是因为它们提供的工具没有使用SQL而SQL正是为此目的而专门设计的。 休眠的经验 我的经验是当您使用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。 翻译自: https://www.javacodegeeks.com/2012/02/problems-with-orms-part-2-queries.html
