所以我有taken over a Java Web project。該應用程序由另一名開發人員編寫，該開發人員現在爲另一家公司工作一般來說，該應用程序非常簡單，設計良好，並且代碼足以記錄在案。唯一的問題是，以前的開發人員決定建立自己的數據庫訪問庫，而不是使用流行的框架。在他的編程生涯多年以來，他構建了一個令人印象深刻的框架來訪問任何數據庫（類似於輕量級的Hiberbate）。可以在同一個項目中使用兩個框架嗎？
現在，我沒有理由拋棄他的代碼，並用更傳統的JPA層替換數據層，因爲當前的代碼工作得很好（儘管它很誘人！）。但我想知道我是否應該使用具有新功能的更傳統的框架。應用程序堆棧非常簡單，我可以輕鬆插入Hibernate或JPA。所以舊的頁面（帶有新的錯誤修正）將使用舊的框架，新的頁面將使用新的框架。
但是，這種方法的缺點之一是它可能會讓新開發人員感到困惑。但是，我也可以繼續使用舊的框架，根據需要擴展/修復它。就像我說的那樣，它起作用！
Eldimo，
您應該平衡納入基於這種變化的投資回報的新框架的決定。目前項目的壽命是觀察它的一種方式。
如果項目穩定並處於維護階段，那麼您不應該進行劇烈的更改。
但是，如果項目將繼續納入新功能並繼續增長，那麼如果增加投資回報，您應該考慮採用受支持的框架。如果您預計當前的本地增長框架發生變化以支持新增功能要求，如果這些要求得到其他現有框架的支持，那麼你就有充分的理由採用它們。
但是，採用新的持久性框架會在短時間內破壞當前項目的穩定性，由於缺乏框架團隊經驗而增加錯誤數量，並且還會影響開發團隊的速度。
做這樣的事情的真正的缺點是一個框架會更改數據庫，而另一個框架不會立即拾取的風險。在使用NHibernate + ADO.NET的組合之前，我遇到了這個問題：如果NHibernate緩存了某些內容，它可能會忽略ADO.NET的更改。
如果你可以減輕這一點，這樣做沒有什麼技術上的錯誤。
你當然不想隨意添加框架，但相反也不好，當存在可接受的替代方案時，編寫自己的僞碼框架。在我的工作中，我們不得不使用Spring從JPA轉換爲更多JDBC風格。在轉換過程中，我沒有刪除或修改任何JPA代碼，只是在JDBC中重新編寫它。一旦我感到舒服，特定的方法工作，我會換出實施。這使我可以在轉換過程中進行拼裝，而不必從服務層下拉出地毯，可以這麼說。因此，要完全回答您的問題，只要計劃遷移到另一個框架，就可以擁有2個框架。
「It works」 - 不要碰！
建立一個案例來完成這項工作可能是值得的 - 性能測試，可伸縮性調查等。如果您找不到合適的理由，請將其留給當前正在使用它的項目。如果有足夠的錯誤引發到數據庫，那麼有一種情況可以遷移到支持良好的後端。如果兩者的性能都很低，那麼原始的JDBC可能是一種改變方式，而不是轉換抽象框架。
在這種情況下，我認爲答案是「是」 ...... 如果你真正可以利用的功能，休眠或JPA具備了傳統圖書館不和如果你肯定你不會破壞當前存在的任何東西。
通過合併Hibernate或JPA，您不僅可以減輕開發團隊的部分維護責任，而且聽起來像您在前進方面會更高興。
只需記錄您的所有更改和您背後的推理，爲了遵循的開發者的利益。
如果它有效並且令人印象深刻，爲什麼會屈服於無理由切換到另一個框架的誘惑？除非目前的框架有一些負面因素（難以維護，難以理解，不可能調試等），否則我會放棄它。