Question

我最近又回到了ASP MVC开发阶段，而对于EF 6，我对设计逻辑提出了一些问题。

我采用以下模式：控制器 - ＆gt;服务 - ＆gt;存储库 - ＆gt; DbContext - ＆gt;数据库

我读了一些关于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并稍后处理它。

问题：

我的存储库是否应该使用实体框架模型（用于构建我的代码优先数据库）？或者repo应该获取它们并使用Automapper或类似的东西立即将EF模型转换为域对象？
服务有什么意义？为什么我不能直接从控制器实例化存储库？该服务的责任是什么？
将实体模型转换为域对象然后转换为ViewModel是正常的流程吗？

Answer 1

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

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

对象的适当设计抽象层？

1 个答案: