需要在遗留世界中休眠[关闭]

1) (…)这是真的吗?

不是的,Hibernate可以处理相当复杂的数据库,包括现有的数据库。但是,它可能无法很好地处理高度非规范化的数据库或异国情调的模式。这是不同的。

这是没有意义的,使用Hibernate并不意味着你不关心优化。我在一个庞大而复杂的STP系统上工作过(几亿美元的预算),性能绝对是一个重要的关注点,我们实际上引入了Hibernate来从延迟加载、二级缓存(以及加速开发)等方面获益。

以下是使用类似Hibernate的ORM时的处理方法(如果合适):

• 绝大多数生成的查询的行为都是正确的(事实上Hibernate会生成 更好的
• 您可以(而且必须)在一定程度上优化查询和休眠。
• 即使您在性能优化上花费了一些时间(包括对于真正有问题的查询返回到本机SQL),您仍然可以更快地完成。

3) (…)因此,在这种情况下,二级缓存没有多大帮助。

4) (…)hibernate适合什么样的项目?它是否适用于没有人关心sql的后台项目?

Hibernate确实非常适合CRUD应用程序,但不仅如此(见上文),而且您的问题显示出一些无知,正如我已经说过的那样。但是,它不适用于任何项目:

• 我可能不会将它用于数据仓库或大型报表应用程序。
• 我可能不会将它用于一个高度非规范化或异国情调的遗留数据库(在这种情况下,像mybatis这样的数据映射器可能是一个更好的选择)。
• 我可能不会将它与使用存储过程的现有系统一起使用。

5) (…)当您的管理员说:请使用memcached进行缓存,请使用此优化查询而不是您的查询时会发生什么?

和我一起讨论 我们是一个团队,而不是互相对抗。

总而言之,ORM解决方案并不总是合适的,但我认为您目前的观点有偏见,我的经验与您问题中表达的观点(错误信念?)不同。

另请参见

• When NOT to use O/R mapping in Java

这对绿地项目有好处,但对遗留项目也有好处。您可能需要使用一些映射技巧,但它提供了相当灵活的映射。

因为您可以使用本机查询,并且可以将其与您最喜爱的缓存解决方案集成,所以您不需要因为使用Hibernate而遭受任何性能问题。当您的数据库管理员说您应该使用memcached时,您可以使用 this memcached/Hibernate integration . 您可以使用您喜爱的缓存和 plug in into Hibernate . 太好了!冬眠有一个 native SQL facility

多应用程序环境对Hibernate的挑战与对任何解决方案的挑战相同。如果您希望您的应用程序运行良好,您将使用相当于二级缓存的缓存。Hibernate恰好提供了一个与缓存集成的ORM。它不能解决跨多个应用程序协调缓存的问题,但是即使不使用Hibernate,也必须解决这个问题。

你的问题可能太宽泛了。我可以告诉你我的经历。

我在一个采用.NET版本(NHibernate)的项目上工作。从单个表加载单个行的简单实现比原始ADO查询慢了近两个数量级。经过多次优化后,我相信他们只把速度降低了一个数量级。

就我个人而言,我真的不喜欢它。它隐藏了有效管理数据所必需的实现细节。我发现没有一个真实世界的应用程序可以通过隐藏数据库细节的数据层的普通实现来执行。 但这可能是我的酸葡萄,因为我是被迫使用它,并责怪它 不能把足够的口红放在猪身上。

2. select * from anytable where anycol = @anyvalue 优化?我不知道。谁也没有。因为只有一个真正的优化标准——这就是此类查询的性能。使用hibernate或其他ORM可以节省大量时间,然后利用这段时间查找 查询速度慢。据我所知,Hibernate有一些使用优化查询的方法。

3. 任何 从数据库读取的数据是脏的,不管它是如何读取的,也不管它存储在哪里。数据阻塞对性能不是好事,所以通常您应该在实际数据和性能之间找到折衷点。

没有银弹。ORM有很多优点,但当它不适合时只有一种严重的情况:它是依赖于参数的动态结果集(当不同的参数返回具有不同列集的数据时)。因为对象结构在编译时是静态的(在静态类型语言中),所以ORM在这种情况下无能为力。

其他案子都能解决。实体服务(更改跟踪等)可以关闭,二级缓存可以禁用,优化查询可以用来代替生成。我不知道如何在冬眠中做所有的事情,但我相信这是可能的。