EJB的簡單但良好的模式

Question

對於以下解決方案，您會建議一個好的，實用但簡單的模式：

• HTML + JSP（作為視圖/演示文稿）
• Servlet（控制器，請求，會話處理）
• EJB（持久性，businesslogic）
• MySQL DB

是否有必要使用自己的DAO層來保持持久性？ 我使用JPA將對象持久保存到我的數據庫中。

我應該從EJB中撤銷業務邏輯嗎？ 所有在線資源都告訴我不同​​的事情並讓我感到困惑......

Answer 1

我肯定會將業務邏輯放在無狀態會話Bean中。 無狀態會話bean很好，因為它們可以很好地捕獲事務邊界。 它將View層與持久層分離。

注意SSB的方法對應於用戶想要實現的小業務目標。

另一點是，您必須確保返回的數據包含對象樹中的所有數據，並且您不依賴於延遲加載來獲取其余數據，因為這會導致所有類型的問題。

盡可能遠離有狀態會話Bean：它們是壞消息，在Web應用程序的上下文中是一個破碎的概念。

對於長時間運行的事情，請考慮使用通過發送JMS消息觸發的消息驅動Bean。 這些是進行后台處理的好方法，可以更快地釋放業務邏輯，縮短事務處理並更快地將控制權交還給最終用戶。

Answer 2

對於使用JSP / Servlets + EJB + MySQL的解決方案，您會建議什么是一個優秀且實用但簡單的模式

使用您選擇的MVC框架，無狀態會話Bean用於業務邏輯和事務管理（如果您不需要遠程處理，則更喜歡本地接口），持久性實體。

盡可能地注入EJB（如果您使用的是Java EE 6，這意味着在任何地方，您也可以跳過該接口）。

是否有必要使用自己的DAO層來保持持久性？ 我使用JPA將對象持久保存到我的數據庫中。

有些人可能會說是，我在大多數情況下都說不。 EntityManager已經實現了域存儲模式，沒有必要為了簡單的需要而將它屏蔽在DAO后面。

您可能需要閱讀以下資源以獲取更多有關此內容的意見：

• JPA殺了DAO嗎？ ，
• JPA / EJB3殺死了DAO ，
• 而最近的DAO並沒有死 - 但它們要么崩潰要么消失了

我應該從EJB中撤銷業務邏輯嗎？

我不會。 將您的業務邏輯放在您的（無狀態）會話Bean中。 EJB3是POJO，它們易於測試，不需要將業務邏輯委托給另一層。

Answer 3

Anno 2012我不建議將Servlet和JSP作為表示層。 這在2002年風靡一時，但那是在十年前。

今天，Java EE有一個名為JSF的優秀MVC框架。 你改善使用它會好得多。 你很可能想從組件庫PrimeFaces中獲取一些Widgets，因為所有標准的Widgets都有點基礎。 像OmniFaces這樣的實用程序庫也是一個很好的補充。

關於DAO; 不要直接使用（JSF）支持bean中的實體管理器，但如果您已經在為業務邏輯使用Service類（事務邊界），那么使用DAO可能會有點過分。

DAO還有一些小的優點，比如dao.findByName（...）看起來比加載命名查詢，設置參數和獲得（單個）結果更清晰，但成本是你必須的為每個實體維護一個單獨的DAO，可能除了一些服務之外。