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，然后有自己的获取/添加/更新方法？

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

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

Answer 1

Blog 和 Post 是否都应该引用 BloggingContext

不 - 类本身不应绑定到特定来源。它们应该只代表一个实体，并且独立于数据的来源。这样可以更轻松地进行单元测试，因为您可以创建一个完全独立于数据源的博客。

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

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

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

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

否 - 因为继承意味着“是”关系 - 并且类保存博客不一定是博客本身。

Answer 2

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

如果您愿意，您还可以在 cmets 中执行上面提到的 @Sergey 并在其上实现存储库接口。我写了一篇关于如何做的博客文章，你可以find here。基本上，您将其设置为具有对 DbContext 类的背景引用的通用存储库，这样您就可以在应用程序代码和数据库逻辑之间建立一个很好的层。