適當的對象設計抽象層？

Question

我最近又回到了ASP MVC開發中，在使用EF 6時，我對設計邏輯有一些疑問。

我正在使用以下模式：控制器->服務->存儲庫-> DbContext->數據庫

我讀了一些有關UnitOfWork模式的內容，但是我總是做類似的事情：

public abstract class BaseRepository : IDisposable
{
    SiteContext Context;
    public BaseRepository(SiteContext context) { 
        Context = context; 
        IsContextDisposable = false; 
    }

    public BaseRepository() { 
        Context = new SiteContext(); 
        IsContextDisposable = true; 
    }
}

public class ForumRepository : BaseRepository
{
}

因此，如果某些方法需要多個存儲庫，則只需將其傳遞給單個DbContext，然后再進行處理即可。

問題 ：

1. 我的存儲庫是否應使用實體框架模型（用於構建我的代碼優先數據庫）？ 還是倉庫應該獲取它們並立即使用Automapper或類似方法將EF模型轉換為域對象？

2. 服務的重點是什么？ 為什么不能直接從控制器實例化存儲庫？ 服務的責任是什么？

3. 將實體模型轉換為域對象然后轉換為ViewModel是正常的流程嗎？

Answer 1

問題2的答案是松散耦合。 如果您直接在控制器中使用存儲庫，這會產生緊密的耦合，並且如果您想更改數據訪問權限，則必須更改控制器。 如果您具有服務層，則無需更改控制器。 現在，如果您的存儲庫基於定義您可能需要的所有數據訪問方法（例如GetBooksByAuthor等）的接口（我們將其稱為IDAL），則可以取消服務層並將存儲庫直接注入到控制器中。 這樣，如果您想更改數據訪問權限，則可以從IDAL接口派生並將此新的具體數據訪問層注入到控制器中。

1和3的答案取決於應用程序的復雜性。 如果您的數據庫表與您的域對象緊密匹配，則存儲庫可以直接使用實體模型。 如果不是，那么最好將它們轉換為域對象，並將其傳遞給服務或控制器以獲取進一步的業務邏輯。 在將域模型發送到視圖之前，通常會在控制器中將其轉換為ViewModel。