我最近看到一個帶有Facade模式的EJB代碼,用於提供表示層(JSF)中使用的一些方法。但是在商業邏輯的某些部分,Facade的方法被調用並被使用。將Facade調用以供內部使用可以嗎?
這似乎有點奇怪,因爲我認爲門面應該服務於外部世界而不是內部功能。我是對的還是偏執狂?
這是一個粗略的(愚蠢)圖來說明情況:
我最近看到一個帶有Facade模式的EJB代碼,用於提供表示層(JSF)中使用的一些方法。但是在商業邏輯的某些部分,Facade的方法被調用並被使用。將Facade調用以供內部使用可以嗎?
這似乎有點奇怪,因爲我認爲門面應該服務於外部世界而不是內部功能。我是對的還是偏執狂?
這是一個粗略的(愚蠢)圖來說明情況:
不,你不應該在我看來。立面用於調節層之間的界面;它不應該從圖層內部使用。
而且它不應該是必需的。我假設getProductById
委託調用某種存儲庫來取得Product
。您可以使用依賴注入來將資源庫注入相應的類中。在我剛剛起草的小型UML示例中(這是一段時間,如果某些連接不正確,請原諒我)我演示了這種方法。
現在Report
類具有訪問ProductRepository
並可以從那裏而不是通過外觀類的去獲取數據。
是的,你說得對! Facade通過隱藏其客戶的複雜性或隨意性提供了一些複雜的界面。客戶端可以是JSF
查看頁面或另一個bean或服務。沒有技術問題,只有當它的工作意圖或責任完全相關。但是一般來說,如果你已經用傳統的方式完成分層,那不應該像你所描述的那樣。
感謝您的貢獻。雖然我接受了Jeroen的回答,但我會給你一些贊成票,因爲你的回答和他一樣好。 –
我認爲你是對的。如果這個函數應該從業務邏輯中使用,那麼它應該將這個函數轉化爲其他實體。 –
在GoF術語中,內部類對Facade一無所知。如果內部類使用Facade,那麼它就成爲Mediator。 – nikita
@nikita,謝謝。那個很好。 –