實體框架類與POCO

Question

我對建築設計有一般意見分歧，盡管不應該使用stackoverflow來征求意見，我想問兩種方法的優缺點，我將在下面描述：

詳細信息： - C＃應用程序 - SQL Server數據庫 - 使用實體框架 - 我們需要決定使用哪些對象來存儲我們的信息並在整個應用程序中使用所有對象

場景1：我們將使用Entity Framework實體來遍歷我們的應用程序，例如，該對象應該用於存儲所有信息，我們將其傳遞給BL，最終我們的WepApi將獲取此實體並返回值。 沒有DTO和POCO。

如果數據庫模式發生更改，我們將更新實體並在使用它的所有類中進行修改。

場景2：我們創建一個中間類 - 稱之為DTO或稱之為POCO - 以保存應用程序所需的所有信息。 有一個中間步驟，即獲取存儲在實體中的信息並填充到POCO中，但我們將所有EF代碼保留在數據訪問范圍內，而不是跨所有層。

每個人的利弊是什么？

Answer 1

我有一個反問題：為什么不兩個？

考慮任何任意MVC應用程序。 在模型和控制器層中，您通常希望使用EF對象。 如果您在使用代碼首先，你已經基本上確定它們是如何在你的應用程序中使用它們定義，然后再設計你的持久層准確地保存在您的應用程序所需要的變化。

現在考慮將這些對象提供給View層。 視圖可能反映您的對象，也可能不反映您的工作對象的聚合。 這通常會導致POCOS / DTO捕獲視圖中所需的任何內容。 另一種情況是您希望在Web服務中發布對象。 許多框架提供了對poco類的簡單序列化，在這種情況下，您通常需要1）注釋您的EF類或2）制作DTO。

另請注意，當您使用POCOS或關閉上下文時，您在EF類上可能存在的任何延遲加載都將丟失。

Answer 2

我會使用中間類，即POCO而不是EF實體。

我看到直接使用EF實體的唯一優勢是它編寫的代碼更少......

改為使用POCO的優點：

您只公開應用程序實際需要的數據

基本上，假設您有一些GetUsers業務方法。 如果你只想讓用戶列表填充一個網格（例如你需要他們的ID，名字，名字），你可以寫下這樣的東西：

public IEnumerable<SimpleUser> GetUsers()
{
    return this.DbContext
        .Users
        .Select(z => new SimpleUser
        {
            ID = z.ID,
            Name = z.Name,
            FirstName = z.FirstName
        })
        .ToList();
}

很清楚你的方法實際返回的是什么。 現在想象一下，它返回了一個完整的User實體，其中包含您不想公開的所有導航屬性和內部內容（例如Password字段）......

它真正簡化了消費您服務的人的工作

對於像商業方法這​​樣的Create更為明顯。 您當然不希望使用User實體作為參數，對於您的服務的消費者來說，知道實際需要哪些屬性會非常復雜......

想象一下以下實體：

public class User
{
    public long ID { get; set; }
    public string Name { get; set; }
    public string FirstName { get; set; }
    public string Password { get; set; }
    public bool IsDeleted { get; set; }
    public bool IsActive { get; set; }
    public virtual ICollection<Profile> Profiles { get; set; }
    public virtual ICollection<UserEvent> Events { get; set; }
}

您需要哪些屬性來使用void Create(User entity); 方法？

• ID：不知道，也許它的產生可能不是
• 名字/名字：那些應該設置
• 密碼：是一個純文本密碼，一個哈希版本？ 它是什么？
• IsDeleted / IsActive：我應該自己激活用戶嗎？ 是通過業務方法完成的嗎？
• 個人資料：哼...我如何影響用戶的個人資料？
• 事件：到底是什么？

它迫使你不要使用延遲加載

是的，我討厭這個功能有多種原因。 他們之中有一些是：

• 非常難以有效使用。 我已經看到太多次代碼產生了數千個SQL請求，因為開發人員不知道如何正確使用延遲加載
• 極難管理異常。 通過允許隨時執行SQL請求（即延遲加載時），您將管理數據庫異常的角色委派給上層，即業務層甚至應用程序。 一個壞習慣。

使用POCO迫使您急切加載您的實體，更好的IMO。

關於AutoMapper

AutoMapper是一個工具，允許您自動將實體轉換為POCO，反之亦然。 我也不喜歡它。 請參閱https://stackoverflow.com/a/32459232/870604