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上面提到的内容，并在其上实现存储库界面。我写过一篇关于你可以做find here的博客文章。基本上，您将其设置为具有DbContext类的背景引用的通用存储库，这样您就可以在应用程序代码和数据库逻辑之间建立一个很好的层。

Answer 2

Blog和Post都应该引用BloggingContext

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

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

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

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

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

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

EF6和业务逻辑层

2 个答案: