EF6和业务逻辑层

Question

我正在尝试使用EF进行下一个项目。

目前我有此代码的第一个代码：

public class Blog
{
    public int BlogId { get; set; }
    public string Name { get; set; }

    public virtual List<Post> Posts { get; set; }
}

public class Post
{
    public int PostId { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }

    public int BlogId { get; set; }
    public virtual Blog Blog { get; set; }
}

public class BloggingContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }
    public DbSet<Post> Posts { get; set; }
}

这样就创建了数据库和表，并且我已经能够添加博客/发布没有问题。 但是我对如何围绕EF代码优先方法进行构造感到困惑。

Blog和Post都应该都引用BloggingContext ，然后拥有自己的get / add / update方法吗？

我是否应该创建单独的BlogManager / PostManager类来实际执行数据的获取/添加/更新并仅返回实体对象？

是否应该创建从Blog / Post继承的包含get / add / update方法的单独类？

Answer 1

DbContext类可以自己处理与数据相关的所有事情。 您不需要在实体类中包括对它们的引用（您也不需要，因为DbContext类打开了数据库连接）。 DbContext还将自己处理基本的CRUD操作（通过使用DbSets<T> ，这是访问特定表中所有数据的简便方法。

如果需要，您也可以执行上面注释中提到的@Sergey，并在其顶部实现存储库接口。 我写了一篇关于这样做的博客文章，您可以在这里找到 。 基本上，您将其设置为通用存储库，并带有对DbContext类的后台引用，从而可以在应用程序代码和数据库逻辑之间建立一个不错的层。

Answer 2

Blog和Post是否BloggingContext引用BloggingContext

不-类本身不应该与特定来源绑定。 它们仅代表一个实体，并且与数据的来源无关。 这样可以简化单元测试，因为您可以创建一个完全独立于数据源的博客。

我是否应该创建单独的BlogManager / PostManager类来实际执行数据的获取/添加/更新并仅返回实体对象？

是的-这通常称为存储库 ，因此BlogRepository和PostRepository可能是更好的名称。

由于两者是相互依赖的，因此最好创建存储库实现的IBLogRepository和IPostRepository接口，这样您就不必紧密耦合存储库了。 然后，当您查询博客并希望将其发布时， BlogRepository可以将请求链接到IPostRepository 。

是否应该创建从Blog / Post继承的包含get / add / update方法的单独类？

否-因为继承意味着“是”关系-以及一个保存博客的类（不一定是博客本身）。