适当的对象设计抽象层？

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。