服務門面（根據Adam Bien） - EJB 3

Question

我讀過Adam Bien重新思考業務層。它提到了創建服務門面，例如OrderService。但是，您是否可以爲大型企業應用程序提供許多服務門面。我有客戶模塊，訂單模塊，運輸模塊，我可以爲每個高級模塊創建一個服務外觀，而不是創建一個包含所有這些模塊的大外觀。所以在我的JSF 2.0 web應用程序，我可以作出這樣一個電話： transportationServiceFacade.findDetails（） orderServiceFacade.findDetails（）

，而不是做這種方式

genericServiceFacade.findDetails（）

我而在我的例子中使用了許多外牆。這會影響性能嗎？

Answer 1

你當然可以。我不知道這本具體的書，但我知道Adam Bien是一位簡單而優雅的執業者。我認爲這很好，特別是如果您與在EJB 2.x時期完成的Enterprise Java解決方案進行比較。但他所採用的簡單也有時會過於簡單化。正如你可能意識到的那樣，隨着你的系統的增長，把一個通用外觀分成更加專業化的其他外牆更有意義。

這當然不會影響性能，因爲這些EJB也將被輪詢。如果有的話，你會消耗更多的內存，但我不擔心這一點，因爲通常先關心你的架構，然後再考慮性能，會更好。即使如此，表演也不應該是「我認爲」的事情，而是「我知道」的事情（即：衡量並向自己證明某件事實際上影響了表演）。

Answer 2

ServiceFacase只是一種模式，您可以將其修改爲套件您的需要。然而，ServiceFacade模式的想法是將單個組件的邊界方法組合成一個單一的類 - 服務門面。如果您需要更多獨立的服務外觀，那麼您也有可能需要更多的解耦組件。


另一個建議是，如果您在前端對單個動作調用兩個不同外觀的方法，最好將該業務邏輯組合到一個外觀中的單個方法中。服務外觀應始終啓動事務，最好減少一個操作中的事務數量，理想情況下爲單個事務。服務門面應該設計用於客戶從外部訪問組件的需求，而不是其他任何事情。