N層體系結構的實際用法

Question

我是一個小型組織的.NET Web開發人員。我們在這裏有一些熟練的開發人員，但我們沒有任何人爲更大，更有組織的軟件商店工作。我們做得很好，但是我發現自己想要更好地構建自己的代碼，只需要很少的地方尋求建議。

談到這一點。在某些情況下，無論何時我們必須做任何數據訪問，我們組織中的某個人決定使用Web服務。因此，我們的硬件架構的組織是如此，這是我們訪問我們數據庫的唯一途徑。這在理論上聽起來不錯，但問題是我們的大多數應用程序的結果會是這樣：

麪條亂七八糟的代碼在aspx.cs - >但這只是調用存儲過程

除此之外Web服務沒有太多分離。每當我開始嘗試研究更好的結構實踐時，我總結了一些關於依賴注入，骯髒的屬性和階級工廠等事情，我的腦袋開始游泳，然後在挫折中轉向別的東西。

下面是我驚奇的一個基本例子。假設我必須創建一個頁面來從列表中選擇員工，編輯他們並更新數據庫。讓web服務返回一個get對象的Employee對象，並接受一個更新的Employee對象會更好嗎？還是讓Employee對象調用webservice來自填充更好？

換句話說：Employee emp = svc.GetEmployee（42）; vs Employee emp =新員工（42）;

第二個例子似乎是更好的更新組織（更新相關屬性並調用emp.Update（）），但問題是如果我需要獲取Employees列表？執行Employee emp = new Employee（id）;將會不一致。對於一個單一的員工，但要做svc.GetAllEmployees（）作爲列表。

我感覺自己在散漫，所以我會停止嘗試解釋並希望有人理解我的困惑。我很欣賞任何人都可以提供的建議。謝謝！

Answer 1

與任何事情一樣，您可以採取多種不同的方法。 （所以希望這裏會有很多不同的答案，因爲這絕對是一個重要的問題。）

有一個問題，你應該問自己你的設計是「多少邏輯需要在應用程序之間共享？」用你給出的小例子GetEmployee，聽起來好像你想知道把模型放到你的域的哪裏。這些模型是否被多個應用程序使用？業務邏輯是否跨應用程序共享？

如果是這樣，那麼你可能希望你的域模型在Web服務之後。也許通過數據訪問和外部依賴關係在這些服務背後建立一個豐富的域（記住依賴注入的事情，最好的設計決定將需要位於服務層後面的域中，因爲這是整個系統的核心）。

那麼，當然，你如何訪問這個邏輯？再次，有很多選擇。我個人最喜歡的設計是有一種抽象服務層的請求/響應系統。對於一個真正斷開連接的異步系統來說，像NServiceBus一樣酷，就像Agatha那樣簡單，只是抽象出實際的服務並將請求/響應邏輯放在代碼中，或者可以用ServiceStack（我一直想要做的事）或另一個項目等。地獄，你可以滾動一個普通的舊的WCF甚至SOAP服務層，只是沒有更多。隨你便。

在這一點上，你正在服務層看一個相當程序化的系統。這不是一件可怕的事情。想想服務層就像一個MVC網站。您向它發送一個請求，並填入某種傳入視圖模型，它在其所有面向對象的優點中執行其域功能，並以傳出視圖模型的某種XML表示形式返回視圖。現在你有一個重複模式。您的客戶端應用程序對您的域名來說只是非常大的視圖。它們的笨重程度越高，它們之間的互換性和可替換性越好。

這使您可以將各種「業務操作」封裝在服務邊界的unit of work中。從客戶端應用程序請求，整個事情成功或整個事情失敗。將其封裝在良好的錯誤處理和應用程序級錯誤/異常記錄器中，爲您提供失敗請求的所有詳細信息。 （想象一下，每個請求都可以被序列化爲一個字符串幷包含在一個錯誤信息中，現在你擁有了用一個簡單字符串重新創建錯誤所需的一切，而不是詢問用戶「你點擊了什麼？」以嘗試重新創建錯誤）。

如果相反，後端並不真正與不同的應用程序共享任何內容，並且每個應用程序都完全是它自己的獨特實體。此時，您並不需要共享服務層背後的所有邏輯，並且完全可能您不應該嘗試進行任何類型的重疊。數據訪問是服務背後的唯一內容嗎？關於文件系統訪問或外部Web服務訪問的內容呢？

如果服務背後的唯一一件事是數據訪問，那麼您可以將您的模型和數據訪問存儲庫保存在您的客戶端應用程序中，就像您習慣的那樣，只需將您的存儲庫實現與內部引用的實現訪問服務層。 （這將成爲您的GetEmployee示例中的第二個選項。）根據應用程序需要存儲的位置，正確抽象的直接訪問與服務訪問存儲庫可以輕鬆地交換出來。

當然，這傾向於一個真正的持久性 - 無知的方法，這可能是危險的。績效影響需要考慮。後端的某些邏輯或工作單元可能會多次訪問數據庫以完成幾件事情。如果這發生在一個服務上，那麼會爲每個數據庫調用增加服務開銷。所以你需要在個案的基礎上解決這個問題。

我想我可能在這一點上是漫不經心的，所以要回到具體的問題，它真的會降低自問一些關於你的域的問題。如何持久無知你能負擔得起嗎？你的應用程序是否共享業務領域邏輯您是否需要訪問服務後面的其他非數據庫外部依賴項？沒有通用的設計總是正確的答案。您最終可能會嘗試各種設計並在適合您的開發人員和您的環境的設計上進行均勻化。