應用程序外觀模式的最佳實踐

我有一個多層SOA應用程序和一個包含超過100個表的數據庫。我爲我的數據層使用了實體框架，它負責所有的CRUD操作。應用程序外觀模式的最佳實踐

我有一個門面類是託管在服務上，可以通過客戶端應用程序全部調用。

此門面類包含諸如

private void DoSomething() 
{ 
    //insert to table1 
    //insert to table 2 
    //delete from table 3 
    //more CRUD operations 
}

而且門面類的方法基本上是滿了類似的DoSomething（）等方法負載

所以客戶端將基本建立正面的實例上課，並獲得所有這些方法。

我現在的問題是，這是門面模式的最佳做法？我覺得門面課程太過「沉重」，我不確定如果我的應用程序規模更大，它是否會影響性能。

如果我有很多方法在裏面，創建一個facade類的實例會是一個非常昂貴的操作嗎？

來源

2012-10-05 Null Reference

那麼，一旦Facade將子系統封裝爲對象併爲所有業務對象和服務提供聚合接口給客戶端，Facade就非常適合SOA體系結構。它還減少了架構中的耦合。我認爲你的方法並不重要，並且不會影響系統的可伸縮性。

來源

2012-10-05 03:13:53

因此，對於Facade類來說，例如60來覆蓋子系統的所有內部工作方式是可以的嗎？ –

儘管這種方法降低了API展會的內聚力，但如果它實現了模式的四個主要目標，我認爲它是可以的：1）使軟件庫更易於使用，理解和測試，因爲Facade具有方便的方法共同的任務; 2）使圖書館更具可讀性，出於同樣的原因; 3）減少外部代碼對庫內部工作的依賴性，因爲大多數代碼使用外觀，因此在開發系統時有更大的靈活性; 4）用一個精心設計的API（根據任務需要）包裝設計不佳的API集合。 –

如果你的Facade簡化了你的子系統的使用，那麼暴露如此多的方法就沒有問題，這就是主意。顯然，如果你的門面不需要堅持每個實例的某個單獨的狀態（並且可能不會），那麼你將實現它作爲一個單例（這是最常見的場景），便宜。 –

將創建門面類的實例是一個非常昂貴操作，如果我有在它的方法加載？

假設這些方法在施工過程中沒有調用，它們應該不會影響對象的「重量」。我的理解是，一個沒有做任何事情的方法不會爲實際目的花費內存或週期。

（作爲一個方面說明，有沒有增值到您問題的技術極限。見How many methods can a C# class have）

讓你的門面爲您工作！一個好的做法是假設你將它交給其他人，並問「這是否很好地描述了我的API的功能是什麼？」。 Sixty聽起來像是達到了我個人偏好的上限，但對於15個對象來說，這仍然只是CRUD。

將立面想象成一個統一的界面，可以讓您創建更加簡潔和複雜的服務（反過來應該封裝更簡潔的存儲庫，而這些存儲庫又應該封裝表格中更簡潔的數據記錄，BLOBS存儲桶等）。

來源

2012-10-06 21:08:28 BlackjacketMack

我知道這有點舊，但你說得對，方法的數量確實不應該有任何影響。方法是JIT編譯的，所以你可以有100個方法並且只使用2個。所以在運行時只有2個會被編譯。 –

應用程序外觀模式的最佳實踐

回答

相關問題