java - 从手写持久层迁移到ORM

Question

我们目前正在评估从手写持久层迁移到 ORM 的选项。

我们有一堆遗留的持久对象(~200)，它们实现了这样的简单接口(interface):

interface JDBC {
    public long getId();
    public void setId(long id);
    public void retrieve();
    public void setDataSource(DataSource ds);
}

当 retrieve() 被调用时，对象通过向使用它在 setter 中收到的 ID 提供的连接发出手写 SQL 查询来填充自身(这通常是查询的唯一参数)。它自己管理它的语句、结果集等。一些对象具有特殊风格的 retrive() 方法，例如 retrieveByName()，在这种情况下会发出不同的 SQL。

查询可能非常复杂，我们经常连接多个表来填充表示与其他对象的关系的集合，有时连接查询是在特定的 getter 中按需发出的(延迟加载)。所以基本上，我们已经手动实现了 ORM 的大部分功能。

这样做的原因是性能。我们对速度的要求非常高，早在 2005 年(编写此代码时)性能测试表明，主流 ORM 都没有手写 SQL 快。

我们现在面临的让我们想到ORM的问题是:

• 此代码中的大部分路径都经过良好测试且稳定。但是，一些很少使用的代码很容易出现很难检测到的结果集和连接泄漏
• 我们目前正在通过向我们的持久层添加缓存来压缩一些额外的性能，并且在此设置中手动维护缓存对象是一个巨大的痛苦
• 当数据库模式发生变化时支持此代码是一个大问题。

我正在寻找对我们来说最好的选择的建议。据我所知，ORM 在过去 5 年中取得了进步，因此现在可能有一个提供可接受性能的对象。当我看到这个问题时，我们需要解决这些问题:

• 找到一些方法来重用至少一些编写的 SQL 来表达映射
• 有可能发出 native SQL 查询，而无需手动分解其结果(即避免手动 rs.getInt(42)，因为它们对架构更改非常敏感)
• 添加一个非侵入式缓存层
• 保留绩效数据。

有什么 ORM 框架可以推荐吗？

更新 了解我们正在谈论的是哪种性能数据:

• 后端数据库是 TimesTen，与 JVM 在同一台机器上运行的内存数据库
• 我们发现将 rs.getInt("column1") 更改为 rs.getInt(42) 带来了我们认为显着的性能提升。

Answer 1

如果您想要一个允许您发出 native SQL 查询的标准持久层，请考虑使用 iBATIS。它是您的对象和 SQL 之间的一个相当薄的映射。 http://ibatis.apache.org/

对于缓存和惰性连接，Hibernate 可能是更好的选择。我没有将 iBATIS 用于这些目的。

Hibernate 提供了很大的灵 active ，允许您在遍历对象图时为延迟加载指定某些默认值，而且当您需要更明确的加载时间时，还可以使用 SQL 或 HQL 查询预取数据到您的核心内容。但是，转换工作对您来说会很复杂，因为它在学习和配置方面具有相当高的入门阈值。注释使我更容易做到这一点。

您没有提到关于切换到标准框架的两个好处:(1) 当你有大量的网站和论坛来支持你时，解决错误会变得更容易。(2) 新员工更便宜、更容易、更快。

祝您在解决性能和可用性问题方面一切顺利。您指出的权衡非常普遍。对不起，如果我传福音。