c# - Entity Framework 类与 POCO

Question

我对架构设计有不同的看法，尽管不应该使用 stackoverflow 来征求意见，但我想询问我将在下面描述的两种方法的优缺点:

详细信息:- C# 应用程序- SQL Server 数据库- 使用 Entity Framework - 我们需要决定我们将使用哪些对象来存储我们的信息并在整个应用程序中使用所有对象

场景 1:我们将使用 Entity Framework 实体在我们的应用程序中四处传递，例如对象应该用于存储所有信息，我们将它传递给 BL，最终我们的 WepApi 将获取该实体并返回值。没有 DTO 或 POCO。

如果数据库架构发生变化，我们会更新实体并修改所有使用它的类。

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

各自的优缺点是什么？

Answer 1

我会使用中间类，即 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:不知道，也许是生成的也许不是
• Name/FirstName:那些应该设置好
• 密码:这是一个纯文本密码，一个散列版本？这是什么？
• IsDeleted/IsActive:我应该自己激活用户吗？是通过商业方法完成的吗？
• 个人资料:嗯……我如何影响用户的个人资料？
• 事件:这是什么鬼？？

它迫使你不使用延迟加载

是的，出于多种原因，我讨厌此功能。其中一些是:

• 极难有效使用。我已经看到太多次产生数千个 SQL 请求的代码，因为开发人员不知道如何正确使用延迟加载
• 极难管理异常。通过允许随时执行 SQL 请求(即当您延迟加载时)，您将管理数据库异常的角色委托(delegate)给上层，即业务层甚至应用程序。一个坏习惯。

使用 POCO 会强制您预先加载您的实体，IMO 更好。

关于AutoMapper

AutoMapper是一个允许您自动将实体转换为 POCO 的工具，反之亦然。我也不喜欢它。参见 https://stackoverflow.com/a/32459232/870604