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类，它们实际上会获取/添加/更新数据并仅返回实体对象？

我应该创建单独的类，它们继承自包含get/add/update方法的Blog/Post吗？

Answer 1

如果Blog和Post都有对的引用

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

我应该创建单独的BlogManager/PostManager类，它们实际上是获取/添加/更新数据并简单地返回实体对象吗？

是 - 这通常称为库，所以BlogRepository和PostRepository可能会更好的名字。

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

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

没有 - 因为继承意味着一个“是”的关系 - 和一类节省一个博客它不一定是博客本身。

Answer 2

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

如果你愿意，你也可以做什么@ Sergey在评论中提到了上述内容，并在其上实现了一个存储库接口，我写了一篇关于如何做到这一点的博客文章find here。基本上，您将其设置为一个通用存储库，其中包含DbContext类的背景参考，以及通过这种方式，你可以在你的应用程序代码和数据库逻辑之间搭起一个很好的层。