使用hibernate却完全不使用表关联查询,这是基于什么原因考虑
2个回答
展开全部
实际项目开发时,选择一个工具,有如下考量:
是否能够解决实际问题;对于 Hibernate 来说,完成实体和表之间的映射,是其主要功能,其他功能都可以按需选择,并不是说,这个工具有什么功能,就都必须用上,工具的使用向来都是跟着问题走的。
时间成本;面对紧张的时间安排,如果项目组所有成员都要学习 Hibernate 到精通,显然是很浪费时间的,而且 Hibernate 也不是看看视频看看书就可以看到实际运用场景的,实际开发中,很多使用 Hibernate 一两年的人也不是很清楚该怎么使用它提供的高级功能,也没时间和心思去翻官方 manual,那么,大家就会想:这个工具大家都不是很熟练,也没有十足的把握用好,那就卖乱只能把它最基本的功能用好算了,也就是,撇开那些高级特性,先用基本功能把活干了再说。
性能;Hibernate 的性能一直饱受诟病,通用工具都难免此类问题,实体加的关联多了,数据加载的就慢,再者,Hibernate 最擅长的并非查询,而是写操作,毕竟是全字段查询,相对来说,JdbcTemplate 就可以指定查询具体哪些字段,自己指定的关联查询 SQL 也比 Hibernate 生成的 SQL 高效简洁,让 JdbcTemplate 负责查询,Hibernate 负责写入,是个不错的搭配。
可维护性;实体关联需要维护,还得控制数据的加载时机(懒加载)、单/双向关系、级联以及抓取策略等,稍微配置不当,就会出现异常,这样的话,与其使用高级功能带来这么中模档多问题,索性干脆不用,省得以后麻烦。
依赖性;项目开发要以数据为核心,数据库修改要灵活轻便,而不依赖于上层工具(如 Hibernate),如果实体添加了太多关联,日后使用其他映射工具或者修改数据库,这些实体就出现问题了,需要对应的修改,毕竟,不是所有工具都像 Hibernate 一样站在对象的角度思考问题的,例如码丛:JOOQ 就提倡 SQL 的使用,反对所有操作都使用 ORM。
是否能够解决实际问题;对于 Hibernate 来说,完成实体和表之间的映射,是其主要功能,其他功能都可以按需选择,并不是说,这个工具有什么功能,就都必须用上,工具的使用向来都是跟着问题走的。
时间成本;面对紧张的时间安排,如果项目组所有成员都要学习 Hibernate 到精通,显然是很浪费时间的,而且 Hibernate 也不是看看视频看看书就可以看到实际运用场景的,实际开发中,很多使用 Hibernate 一两年的人也不是很清楚该怎么使用它提供的高级功能,也没时间和心思去翻官方 manual,那么,大家就会想:这个工具大家都不是很熟练,也没有十足的把握用好,那就卖乱只能把它最基本的功能用好算了,也就是,撇开那些高级特性,先用基本功能把活干了再说。
性能;Hibernate 的性能一直饱受诟病,通用工具都难免此类问题,实体加的关联多了,数据加载的就慢,再者,Hibernate 最擅长的并非查询,而是写操作,毕竟是全字段查询,相对来说,JdbcTemplate 就可以指定查询具体哪些字段,自己指定的关联查询 SQL 也比 Hibernate 生成的 SQL 高效简洁,让 JdbcTemplate 负责查询,Hibernate 负责写入,是个不错的搭配。
可维护性;实体关联需要维护,还得控制数据的加载时机(懒加载)、单/双向关系、级联以及抓取策略等,稍微配置不当,就会出现异常,这样的话,与其使用高级功能带来这么中模档多问题,索性干脆不用,省得以后麻烦。
依赖性;项目开发要以数据为核心,数据库修改要灵活轻便,而不依赖于上层工具(如 Hibernate),如果实体添加了太多关联,日后使用其他映射工具或者修改数据库,这些实体就出现问题了,需要对应的修改,毕竟,不是所有工具都像 Hibernate 一样站在对象的角度思考问题的,例如码丛:JOOQ 就提倡 SQL 的使用,反对所有操作都使用 ORM。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询