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類的背景參考，以及通過這種方式，你可以在你的應用程序代碼和數據庫邏輯之間搭起一個很好的層。