我的开发团队应该使用Hibernate吗？

Question

简介
我是我开发团队中最新的人。我们主要进行Java Web开发并使用Oracle数据库，但在极少数情况下我们使用其他RDMS。为了扩展我的专业知识和探索更现代的方法，我决定学习Hibernate。

到目前为止，我不确定它是否适合我们的团队 - 但我不知道是不是因为Hibernate合法地不适合我们的需求，或者因为我们遵循这样的不良做法，以至于Hibernate“不愿意”来沿。

例如，几乎我们与数据库的所有交互都是通过标准的JDBC CallableStatements和存储过程。我们遍历ResultSet并将它们放入bean / pojos中以供Web应用程序使用。据我所知，Hibernate喜欢精确地建模表（@Entity，@Table）及其列。对于简单的SELECT查询，这是一种稍微简单的方法。但是，对于精心设计的数据库工作（想想对原始数据运行分析），我要么大量操作我的Java代码中的数据（并放弃最终映射表的实体类），要么通过丑陋的{调用存储过程}。 {1}}，这似乎打败了使用Hibernate开始的整个过程。

假设我不知道： 我的团队很早就告诉我他们认为在数据库（即存储过程）中而不是在app服务器（即Java）中做“繁重”更好，我不知道他们是对还是错。如果他们是对的，那么为什么像Hibernate这样的ORM会存在？

另外，我[{3}}认为Hibernate的学习曲线相当僵硬，但我觉得我完全忽略了这一点。数据库表是否应该完全模仿Web应用程序中所需的数据？我们的设计方法是否已经不复存在了？

最后，我知道存储过程与ORM是一个热门heard，但趋势似乎是在ORM的“一面”。为什么呢？

TL;博士 Hibernate似乎只能帮助我们处理大多数情况下的用例，并将一堆复杂的配置和额外的资源作为权衡。我错过了什么？

Answer 1

长话短说，如果您在项目中质疑Hibernate的使用，请不要使用它。更好地设计DAO和DTO，以便日常操作不会花费太多精力来实现。另外，请参阅Spring JDBC模板，其功能可能对您有所帮助。

P.S。如果您的团队不熟悉Hibernate，那么使用

将会非常困难

Answer 2

我只是分享我的经验。我正在开发一个项目，应用层之间有明确的分离;我的团队负责服务器端代码，另一个团队负责数据库，另一个团队负责配置和维护应用程序容器。在这种情况下，Hibernate（一般来说是一个ORM）允许我们从数据库实现细节中独立（我知道，而不是完全）。

从我的观点（但这取决于数据库结构）的另一个优点是可能性，并且我发现这种可能性非常有用，可以使用Java和OO模式浏览表关系。在这种情况下，请考虑延迟加载。

祝你好运！