[英]When should I use POJO (instead of EJB) in a Java EE application?
我目前正在學習JAVA EE。 我使用oracle Java EE 7教程。 根據本教程的第34.1.4節，他們在教程示例中使用了一些非EJB輔助類。 http://docs.oracle.com/javaee/7/tutorial/doc/ejb-basicexamples001.htm
我想知道在什么情況下我應該創建一個類EJB，在什么情況下我應該使用通常的幫助器類。 我已經了解了使用EJB的好處。 但是有沒有使用POJO更好的情況？
簡短的回答是“除非您需要特定的EJB工具”。
更長的答案如下。 多年前，當使用EJB之前的3.0時，EJB是“沉重的”。 你必須實現接口，從基類繼承你的bean等。很簡單，EJB只能在容器中使用。 這意味着為EJB編寫單元測試非常困難。
因此，人們使用以下策略。 他們在EJB需要時在POJO中實現了所有可能的功能。 解決方案很冗長（因為有些東西是重復的）但非常模塊化且更易於測試。
自從引入EJB 3.0以來，POJO或EJB之間幾乎沒有區別。 實際上，EJB是一個帶有一些注釋的POJO。 這意味着您不必創建POJO，然后使用瘦EJB層將其包裝起來。 您可以在類中實現所有內容（如果需要，可以將其稱為POJO），然后使用注釋將其轉換為EJB。 仍然因為委托是好的，所以更多的代碼是EJB注釋 - 越少越好。
管理EJB組件（由容器管理），這意味着一些額外的開銷。 Fly有一個名為Sledgehammer的反模式：
描述了EJB（一種帶有額外開銷的技術）是在簡單的POJO上選擇的，其中只需要輕量級處理。 產生額外的復雜性; 沒有明顯的好處
解決方案：
如果您的代碼不使用以下容器服務，請使用POJO ：
我想補充一點，在很多情況下，EJB就像Service Facades / Services一樣使用。 當您想要使用設計模式（CDI對象或POJOS）處理業務邏輯而不是僅使用EJB以過程方式放置邏輯時，存在真實場景。 重新定義：EJB服務外觀是解決復雜業務需求的設計模式的單一入口點（如果您不需要設計模式，請不要使用它，保持簡單！）。
資料來源：飛行大錘，服務門面，服務：
我應該在哪里（確切地）在我的Java EE應用程序中使用同步
[英]Where (exactly) should i use synchronization in my Java EE application
Java EE應用程序中的實用程序類應該是EJB的類還是具有靜態方法的類
[英]Should utility classes in Java EE application be EJB's or classes with static methods
Windows Server上的簡單Java應用程序......我應該使用Java EE嗎？
[英]Simple Java app on a Windows Server … should I use Java EE
我應該如何在分層Java EE應用程序中設計插件系統？
[英]How should I design a plugin system in a layered Java EE Application?
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.
