对象的适当设计抽象层？

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
{
}

因此，如果某个方法需要多个 repos，它可以只传递其单个 DbContext 并在以后处理它。

问题：

1. 我的存储库是否应该使用实体框架模型（用于构建我的代码优先数据库）？或者 repo 是否应该获取它们并立即使用 Automapper 或类似的东西将 EF 模型转换为域对象？

2. 服务的意义何在？为什么我不能直接从控制器实例化存储库？服务的职责是什么？

3. 将实体模型转换为领域对象然后再转换为视图模型是否正常？

Answer 1

问题 2 的答案是松散耦合。如果您直接在控制器中使用存储库，这会产生紧密耦合，并且如果您想更改数据访问权限，则必须更改控制器。如果您有服务层，则无需更改控制器。现在，如果您的存储库基于一个接口（我们称之为 IDAL），该接口定义了您可能需要的所有数据访问方法（例如 GetBooksByAuthor 等），您可以取消服务层并将存储库直接注入您的控制器。这样，如果您想更改数据访问，您可以从 IDAL 接口派生并将这个新的具体数据访问层注入您的控制器。

1 和 3 的答案取决于您的应用程序的复杂性。如果您的数据库表与您的域对象非常匹配，那么 repo 可以直接使用实体模型。如果没有，那么最好将它们转换为域对象并将它们传递给服务或控制器以进行进一步的业务逻辑。领域模型通常会在控制器中转换为 ViewModel，然后再发送到视图。