我的服務層方法應該完全封裝一個工作單元嗎？

Question

我在考慮重構我的一些C＃代碼，其中我已經使用實體框架6實現了存儲庫模式。它是一個ASP.NET MVC4網站。目前，我已經在我的存儲庫之上建立了一個服務層。服務層持有我的業務邏輯，如獲得所有用戶，其中X大於Y等

我的一個類似的項目，相同的實現是在這裏：https://github.com/ryancole/BetterArmory

眼下，一個客戶端我的圖書館會用我的圖書館，像這樣（沒有DI爲簡潔起見）：

using (var context = new MyDbContext()) 
{ 
    var userRepository = new MyUserRepository(context); 
    var userService = new MyUserService(userRepository); 

    var user = userService.getById(1); 

    user.Name = "Foo Bar"; 

    context.SaveChanges(); 
} 

以上，MyDbContext是我的課，從EF6的繼承的DbContext。我的MyUserRepository存儲庫類和所有其他回購，將上下文作爲arg。此外，服務類將適當的存儲庫類作爲arg。因此，我在想重構的東西是這個實現的泄漏，我覺得。在大多數情況下，從我的服務層返回的類都是EF6代理，並且可以直接使用SaveChanges方法在DbContext上修改，保存這些更改。這對我來說很難執行驗證，因爲我正在使用EF似乎沒有任何知識的Fluent驗證。據我所知，我必須在我的服務層方法中手動撥打Fluent Val的Validate。這很糟糕，因爲對代理對象的直接更改不是通過服務層方法執行的。即使我有一個名爲SetUserEmail的服務層方法，其中我使用Fluent Val驗證了實體，但用戶仍然可以直接編輯代理屬性。

所以我想知道，讓我的服務層初始化DbContext，存儲庫並執行更改，調用任何所需的Fluent Val東西等等，都可能更好嗎？

這個問題的一些缺點可能是，延遲加載必須在服務方法中明確表示，或者只是一起禁用並加載所有內容。這是我現在能夠想到的，但我知道我還有其他的缺點，我想到了。

Answer 1

對我來說，把UoW（在這種情況下是DbContext）封裝到服務層是有意義的。服務是一種交易行爲，可以將一個或多個數據庫操作跨越到一個事務中，如果一個操作失敗，整個服務將失敗。

通常，應用程序層不應該瞭解DbContext及其存儲庫。它應該將所有邏輯操作委託給服務層。在MVC的情況下，這將產生一個瘦的控制器，其唯一的責任是根據服務調用的結果來決定正確的路由/重新路由。

可以在服務層中進行延遲加載，加載所有內容都會導致嚴重的性能問題。

我已經構建了一個在線腳手架工具，演示了這種架構。如果你有興趣，你可以在Camote Q查看。