持久层 技术选型如何决策？JPA，Hibernate，ibatis(mybatis)

持久层 是一个项目 后台 最重要的部分。他直接 决定了 数据读写的性能，业务编写的复杂度，数据结构(对象结构)等问题。

因此 架构师在考虑 使用那个持久层框架的时候 要考虑清楚。
选择的 标准：
1，项目的场景。
2，团队的技能掌握情况。
3，开发周期(开发效率)。

传统的 业务系统，通常业务都比较复杂，懂业务的运维人员 对sql查询工具都比较熟悉。
这种以 数据库 为主的 业务场景 使用 以sql为主的持久层框架 例如：ibatis，mybatis
这种 性能优化的时候 sql 语句调整较为方便，甚至 业务人员 会直接提供 业务对于的 sql给开发人员。

对于快速迭代的中小型 新项目，适合使用hibernate(JPA + hibernate驱动)。
快速迭代 适合 使用面向对象的 持久层框架。在开发过程中 对象的变更非常频繁。
这种 持久层框架 适合 快速 重构 ，提高开发效率。
但是 这种框架 易学难精，用的不好就容易造成性能问题，用的好性能并不输于ibatis框架。
在做性能优化方面 可借助 缓存实现。

以上说说到了 项目场景 和 开发效率。
再说说 团队技能掌握情况，这个情况 有的时候 可以忽略，但有时缺不能忽视。
这个情况也和上面说的两个情况 对比着 分析，需要做一个平衡。
分以下几个情况：
老团队新项目：

    这个要考虑 是重用公司已有框架资源，持续积累改进，还是放弃旧的，开发新的。    这个时候，大部分开发人员会怂恿技术主管或架构师 使用新的框架，尝试新的技术；不关心新技术带来的风险，项目的进度，已用积累的放弃。    作为架构师/技术主管，需要考虑项目的场景，周期，核心点，公司技术的可持续积累，风险性，团队技术的培训提升 等方面综合考虑。    结论：结合项目场景适度引进新技术(这也是提升团队技术的一个机会，但风险与机会并存，进度紧张的时候不建议更换）。

新项目新团队：

    这个要区分地方，大城市好招人，以项目场景为主，选择框架，招聘精通此类框架的人才即可；    小城市 招聘人才困难，如果 没有 技术牛人引导使用，建议 还是要以团队技术人员掌握的技术为主。    一群人 用一个不熟悉的框架，不如 大部分用一个熟悉的框架。(技术培训 是需要一个周期的，如果没有牛人不建议现学现用)。    这里 可能有另外一个声音：大家一起学，边学边用。在项目非紧急的情况下 可以考虑。    但本人不太建议拿项目当试验；稳定，高效，靠谱，好扩展，这是作为一个架构师 要肩负的责任。

以技术为核心的项目：

    要招聘一些技术牛人，使用符合项目场景的框架，而不是复合团队的框架，但团队技术问题 要通过培训，牛人带路等方式解决。

原文地址： http://t.51jdy.cn/thread-259-1-1.html