物理中間層分離應用程式

Question

我已經設計了不少最近的Windows窗體應用程序（數據輸入應用程序，辦公一體化，等等），雖然我總是設計時考慮到邏輯層中， 「中間層」業務邏輯層始終託管在桌面PC（即物理客戶端 - 服務器）上。

當我接近更復雜的應用，我發現自己渴望有一個物理中間層，而不是與傳遞請求返回到應用服務器來處理業務邏輯（可定期更改）和接口的桌面客戶端。這感覺就像我錯過了一些因素，比如更適合Web應用程序的可伸縮性和可維護性。

我很好奇，想知道的WinForms多遠其他開發商都採取了中間層的分離：

• 多少處理（如果有的話），你在中間層服務器上執行？
• 你使用什麼通信方式 - WCF，遠程處理，網絡服務等？
• 性能是多少因素，以及您往返服務器的頻率？

將業務邏輯轉移到單獨的層上還是有好處的，還是在PC上本地託管組件更爲實用（並確保您有一個良好的部署模型，以將常規版本推出爲業務規則改變）？

或者，我應該從WinForms的指導客戶完全消失，如果這些因素都參與？隨着諸如Silverlight甚至ASP.NET和AJAX等替代品的出現，選擇WinForms客戶端的原因似乎在縮小。

Answer 1

要記住的重要一點是，在獨立的中間層開發的易用性與所有可伸縮性優勢等之間有一個折衷。我的意思是你必須刷新接口映射在你的代碼中，你必須在某個地方部署一箇中間層供你的測試人員使用，這需要刷新等。此外，如果你像我一樣懶惰，直接傳遞你的Entity Framework對象，你不能將它們串行化到中間因此您需要爲您的所有操作創建DTO's等。

這些開銷中的一部分可以通過體面的構建系統處理，但也需要努力設置和維護。

我的首選策略是保持程序集方面的物理分離（即我有一個單獨的業務邏輯/數據訪問程序集），並通過接口層將所有調用路由到業務層，這是一堆門面類。所有這些程序集都駐留在我的Windows應用程序中。我還爲所有這些外牆創建接口，並通過工廠訪問它們。

這樣，我應該需要中間層的分離，並且在生產力方面的權衡是值得的，我可以將業務層分開，放在WCF服務後面（因爲這是我的首選的服務平臺），並根據我的外觀發佈的內容以及他們接受的內容進行一些重構。

Answer 2

根據您的應用程序，需要注意幾個性能問題。

如果你的工作是不同的客戶端（共享數據）之間非常相似，然後做一箇中間層的處理更好，因爲你可以利用緩存以減少整體的處理。

如果你是客戶（私人數據）之間的不同，那麼你就不必通過在中間層做處理多少收穫。

Answer 3

這是我傾向於總是在網絡環境中工作的一個例子。如果網絡可用於您的客戶端應用程序進行服務調用，則它肯定可用於從Web服務器發送和檢索數據。

當然，客戶端限制可能會改變您的最終路徑，但是當有機會影響方向時，我會轉向基於Web的解決方案。有一些可用的部署技術可以爲您提供比傳統桌面軟件包更容易的升級途徑，但是無法替代更新基於服務器的應用程序。