持久層 是一個專案 後臺 最重要的部分。他直接 決定了 資料讀寫的效能，業務編寫的複雜度，資料結構(物件結構)等問題。

因此 架構師在考慮 使用那個持久層框架的時候 要考慮清楚。
選擇的 標準：
1，專案的場景。
2，團隊的技能掌握情況。
3，開發週期(開發效率)。

傳統的 業務系統，通常業務都比較複雜，懂業務的運維人員 對sql查詢工具都比較熟悉。
這種以 資料庫 為主的 業務場景 使用 以sql為主的持久層框架 例如：ibatis，mybatis
這種 效能優化的時候 sql 語句調整較為方便，甚至 業務人員 會直接提供 業務對於的 sql給開發人員。

對於快速迭代的中小型 新專案，適合使用hibernate(JPA + hibernate驅動)。
快速迭代 適合 使用面向物件的 持久層框架。在開發過程中 物件的變更非常頻繁。
這種 持久層框架 適合 快速 重構 ，提高開發效率。
但是 這種框架 易學難精，用的不好就容易造成效能問題，用的好效能並不輸於ibatis框架。
在做效能優化方面 可藉助 快取實現。

以上說說到了 專案場景 和 開發效率。
再說說 團隊技能掌握情況，這個情況 有的時候 可以忽略，但有時缺不能忽視。
這個情況也和上面說的兩個情況 對比著 分析，需要做一個平衡。
分以下幾個情況：
老團隊新專案：

    這個要考慮 是重用公司已有框架資源，持續積累改進，還是放棄舊的，開發新的。
    這個時候，大部分開發人員會慫恿技術主管或架構師 使用新的框架，嘗試新的技術；不關心新技術帶來的風險，專案的進度，已用積累的放棄。
    作為架構師/技術主管，需要考慮專案的場景，週期，核心點，公司技術的可持續積累，風險性，團隊技術的培訓提升 等方面綜合考慮。
    結論：結合專案場景適度引進新技術(這也是提升團隊技術的一個機會，但風險與機會並存，進度緊張的時候不建議更換）。
 

新專案新團隊：

    這個要區分地方，大城市好招人，以專案場景為主，選擇框架，招聘精通此類框架的人才即可；
    小城市 招聘人才困難，如果 沒有 技術牛人引導使用，建議 還是要以團隊技術人員掌握的技術為主。
    一群人 用一個不熟悉的框架，不如 大部分用一個熟悉的框架。(技術培訓 是需要一個週期的，如果沒有牛人不建議現學現用)。
    這裡 可能有另外一個聲音：大家一起學，邊學邊用。在專案非緊急的情況下 可以考慮。
    但本人不太建議拿專案當試驗；穩定，高效，靠譜，好擴充套件，這是作為一個架構師 要肩負的責任。

以技術為核心的專案：

    要招聘一些技術牛人，使用符合專案場景的框架，而不是複合團隊的框架，但團隊技術問題 要通過培訓，牛人帶路等方式解決。