Java EE 6設計模式

Question

我想知道可以在Java EE 6實現中應用的設計模式。

• MVC。
• GOF。
• DAO
• 持久性關係映射
• 池
• CEC
• 實體控制邊界（ECB）
• 和許多其他

待辦事項JPA杜絕使用DAO的？
請提供其他可以學習的模式。

Answer 1

如果您使用Java EE 6（而不是Java EE 5），那麼J2EE中使用的任務不再需要某些技術J2EE模式。

例如，使用注入而不是ServiceLocator。

@see http://pawelstawicki.blogspot.com/2010/07/review-real-world-java-ee-patterns.html

---

GOF模式仍然需要，因爲他們不（僅）與Java EE。

一般來說：模式有一個打算：他們想爲問題產生一個解決方案/最佳實踐，並且提供一套由環境提供的功能（在你的情況下：它是Java，Java EE 6， ...）

• 如果問題消失的方式：你不再需要
• 模式如果環境發生了變化，因爲該模式是喜歡，那麼你必須重新思考模式，因爲可能的問題是走了（第一點），或者現在有更好的方法來處理問題。

Answer 2

這是一個很好的參考這裏：http://martinfowler.com/eaaCatalog/

另外這裏：http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

此外，JPA不一定消除對DAO層的需要。相反，您的DAO層仍然可能會在finder方法內構建JPA查詢，並返回這些查詢返回的實體。

您可以消除DAO層，而直接在您的業務層中直接訪問JPA實體，但個人仍然希望維護單獨的持久性（DAO）和業務層，特別是在最終不得不混合使用普通的JDBC提供一些JPA等。

關於辯論here有一個很好的總結。最好的答案是，這取決於。如果你的應用程序很複雜，並且在某些情況下你可能直接訪問JDBC（因爲JPA和ORM工具不是一切的答案，並且在某些情況下很糟糕），或者如果你需要從源代碼中提取數據在ORM中不能很好地工作，無論如何你需要一個DAO層，所以在我看來，我寧願保持一致，並且爲每件事都使用DAO層。它通常不那麼複雜，它將您的業務邏輯與持久性邏輯隔離開來，我認爲這是一件好事。但是，這是一個個人喜好的問題，如果你的應用程序適合簡單，那可能是矯枉過正。

對於JPA here可以使用通用DAO模式的一個很好的建議。這使您可以享受DAO帶來的好處，因爲您始終可以針對特定的DAO重寫此操作，同時保持更加標準和典型的數據庫交互更簡單。