會話外觀核心J2EE模式的優點和缺點是什麼？

Question

會話外觀核心J2EE模式的優點和缺點是什麼？

背後有什麼假設？

這些假設在特定環境中是否有效？

Answer 1

Session Facade是一個奇妙的模式 - 它確實是商業門面模式的特定版本。這個想法是將業務功能綁定到分立的包中 - 比如TransferMoney（），Withdraw（），Deposit（）...這樣你的UI代碼就可以訪問業務操作而不是低級數據訪問或其他細節它不應該被關注。

特別是在會話Facade中 - 您使用Session EJB來充當業務外觀 - 這是很好的原因，那麼您可以利用所有J2EE服務（認證/授權，事務處理等）...

希望可以幫到...

Answer 2

會話外觀模式的主要優點是您可以通過業務功能將J2EE應用程序劃分爲邏輯組。會話Facade將由UI中的POJO（即業務代表）調用，並引用相應的數據訪問對象。例如。 PersonSessionFacade將被PersonBusinessDelegate調用，然後它可以調用PersonDAO。 PersonSessionFacade上的方法至少會遵循CRUD模式（創建，檢索，更新和刪除）。

通常，大多數會話外觀都是作爲無狀態會話EJB實現的。或者，如果您在Spring地區使用AOP進行交易，則可以創建一個POJO服務，該POJO可以是您的交易管理器的所有連接點。

SessionFacade模式的另一個優點是任何具有一定經驗的J2EE開發人員都會立即理解您。

SessionFacade模式的缺點：它假定特定的企業架構受到J2EE 1.4規範的限制（請參閱Rod Johnson的書中的這些批評）。最具破壞性的缺點是它比必要更復雜。在大多數企業web應用程序中，您將需要一個servlet容器，並且Web應用程序中的大部分壓力都將位於處理HttpRequest或數據庫訪問的層。因此，將servlet容器部署在與EJB容器不同的進程空間中似乎不值得。即遠程調用EJB創造更多的痛苦而不是獲得。

Answer 3

羅德約翰遜聲稱，主要的原因，你想使用一個會話外觀是如果你正在做的容器管理的事務 - （比如Spring），這是沒有必要用更現代的框架

他說，如果你有業務邏輯 - 把它放在POJO中。 （我同意 - 我認爲它是一種更加面向對象的方法 - 而不是實現會話EJB。） http://forum.springframework.org/showthread.php?t=18155

很高興聽到對比的論點。

Answer 4

看來，無論何時您談論與J2EE有關的任何事情 - 在幕後總會有一大堆假設 - 人們會採用某種方式或其他方式 - 這會導致混淆。 （我可能也可以讓問題更清楚。）

假設（一）我們想通過EJB規範使用容器管理的事務在嚴格意義上，然後

會議外立面是一個好主意 - 因爲它們抽象掉了低級別的數據庫事務，以便能夠提供更高級別的應用事務管理。

假設（二）你指會話外觀的一般建築理念 - 然後

解耦服務和消費者，並提供了這頂一個友好的界面是一個好主意。計算機科學通過「添加額外的間接層」解決了很多問題。

Rod Johnson寫道：「帶有遠程接口的SLSB爲通過RMI構建的分佈式應用程序提供了一個非常好的解決方案，但這只是一個少數要求，經驗表明我們不希望使用分佈式體系結構，除非被要求強制。如果有必要，我們仍然可以爲遠程客戶提供服務，通過在一個良好的共存對象模型之上實現遠程外觀。「 （約翰遜，R「J2EE開發無EJB」 P119），您認爲EJB規範（特別是會話外觀組件）

假設（C）是對優秀設計的景觀枯則：

Rod Johnson寫道：「一般來說，在Spring應用程序中使用本地SLSB的原因並不多，因爲Spring提供的功能比EJB更有能力的聲明式事務管理，而CMT通常是使用本地SLSB的主要動機。因此，你可能根本不需要第三層EJB層。「http://forum.springframework.org/showthread.php?t=18155

在Web性能和可伸縮性的環境中服務器是主要問題 - 而且成本是一個問題 - 那麼會話外觀架構看起來不那麼吸引人 - 與數據庫直接對話可能會更簡單（儘管這更多地是關於分層。）