实体框架类与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 会迫使你急切地加载你的实体，在我看来更好。

关于自动映射器

AutoMapper是一个工具，可让您自动将实体转换为 POCO，反之亦然。我也不喜欢它。请参阅/sf/answers/2272146271/