具有DAL，回購，服務，API層的N層體系結構：每層應處理哪些類型的對象/應該在哪裏進行驗證/映射？

Question

我想我的應用程序應該至少具有以下層：

• DAL（不常用的接口;充分利用數據庫中的數據，得到從其他網絡服務的數據，從文件中獲取數據）
• 庫（CRUD接口爲每個重要/根骨料;實現由源而異）
• 服務（消耗儲存庫接口;實現由商業邏輯而異）
• 網絡API（渦卷服務;安裝容器;實現由運行參數而變化/ config）

我知道我的Web API應該返回DTO，我將其解釋爲只有自動實現的公共屬性的C＃對象。

從理論上講，有時候我需要做BigComplicatedServiceCommand，其中一個工作單元將涉及多個存儲庫，但有時我的Web API可能會直接調用存儲庫，因爲它只是在執行CRUD。

我有興趣瞭解其中從（通過web api模型綁定輸入到web服務的輸入）映射到服務需要應該發生的任何事情 - 以及驗證應該發生的地方。

粗略地說，我有這個在我的腦海：

在API

1. 接收請求，並映射到路線
2. 使用模型綁定按照慣例綁定到DTO
3. 實例化特定的控制器使用IoC容器
4. 運行特定控制器操作
5. 在控制器操作，打電話到服務層

現在，在步驟5之後是有問題的。我是否會將DTO發送到服務？然後，我的服務將與我的DTO配合使用。

我是否爲每種服務方法定義了特定的接口？如果是這樣，這些實際上是他們自己的DTO，我也可以定義一個DTO每服務輸入排列。

假設我的服務需要在DTO，

1. 在服務方法，做商業邏輯做出庫
2. 在倉庫，CRUD的東西通話
3. 返回最終的結果從服務方法API
4. 投向DTO並從API返回到互聯網

現在，如果我的存儲庫嚴格處理域對象？如果是這樣，誰來負責鑄造？ （服務？）

最後，記住驗證，我想到的是：

• 驗證的前期使用下列之一：ModelStateActionFilter（行動之前執行），鑄造到任何服務需要的輸入是在。因此，這將確保CreateUserService正在接收Username和Password的對象。
• 驗證服務方法使用資料庫和其他服務的用戶名是唯一的，密碼是足夠強大
• 驗證在DAL水平，以確保實體框架是幸福

我的問題是，它（如果有的話）的對象我應該在System.DataAnnotations上嗎？在這個堆棧中是否有任何類型的模型應該對任何部分負責自己的驗證？

感謝您的任何哲學幫助。

Answer 1

這個問題......

因爲你的問題很長我可能會錯過解決一些點，但在這裏我們去。順便說一句，這是「我認爲的」，你應該改變你認爲合適的東西，以更好地滿足你的需求。

1. 擺脫「N層」一詞。這些天涼爽的孩子們正在使用「洋蔥建築」。

2. 從「Core」項目開始。這是你所有的核心對象將坐落在哪裏。您將擁有客戶，訂單，產品等。在此級別，不必擔心數據庫，Web API或UI。你的對象應該有方法，屬性和行爲。在這裏，一切都不應該是Public { get; set; }。哦，不要使用接口，如果你沒有在這裏明確需要它們。

3. 在您的「Core」項目之後，您可以擔心如何存儲這些對象。您可以創建一個「Repository/DAL」項目。您的存儲庫應該採用您的聚合根。弄清楚如何把它放在數據庫中是個工作。

4. 現在「服務」項目。服務很簡單。您的服務負責：從存儲庫獲取對象，在對象上調用方法，將對象放回存儲庫。現在，您的服務可以返回或接受「核心」對象，或者公開他們自己的DTO。

5. 您的WEB API/MVC項目將與您的用戶進行交互。它會調用服務來獲得任何想要的東西。在這裏，您可以使用視圖模型向用戶展示而不是核心對象。

- 確定that't它 -

但這裏有一些明確的解答您的疑問：

1. 網絡API不應該直接調用庫。

2. 無論您的服務返回到Web Api映射DTO/View模型應該發生在Web Api項目中。

3. 驗證：Web Api可以驗證所有內容以幫助用戶。另外，Core應該很好地驗證，核心內容等等......驗證將會在很多地方結束。

4. 不要爲每個服務定義接口。如果只有一個實現，它的概率不應該是一個接口。

5. 在服務方法中，您不會執行業務邏輯。邏輯進入核心對象內部。

6. 是的，存儲庫嚴格使用核心/域對象。是的，服務部門將工作交給他們。

7. System.DataAnnotations進去的Web API 「查看/模型/ DTO的」