实体框架类与POCO

xmorera 发表于 Dev

Xmorera

我对体系结构设计有普遍的意见分歧，尽管不应使用stackoverflow征求意见，但我仍想对两种方法的优缺点进行讨论，以下将对此进行介绍：

详细信息：-C＃应用程序-SQL Server数据库-使用实体框架-我们需要确定要使用哪些对象来存储信息并在整个应用程序中使用所有对象

场景1：我们将使用Entity Framework实体在我们的应用程序中传递所有内容，例如，应使用对象存储所有信息，将其传递给BL，最终我们的WepApi将采用该实体并返回值。没有DTO或POCO。

如果数据库架构更改，我们将更新实体并在使用实体的所有类中进行修改。

方案2：我们创建一个中间类-称为DTO或称为POCO-来保存应用程序所需的所有信息。有一个中间步骤，获取存储在实体中并填充到POCO中的信息，但我们将所有EF代码保留在数据访问范围内，而不是跨所有层。

每个优点和缺点是什么？

ken2k

我将使用中间类，即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);方法需要哪些属性？