时间戳

首页 > 解决方案 > 域数据模型中的非持久属性

c# - 域数据模型中的非持久属性

问题描述

我听说对于一个小项目，不推荐使用 DTO，例如这里和这里。我想知道一个相当小的项目（团队方面）是否可以合并域模型中的非持久属性？例如：

namespace Domain.Entities
{
    public class Candidate : BaseEntity
    {
        public Candidate()
        {
            // some construction codes
        }

        // region persistent properties

        public string FirstName { get; set; }
        public string LastName { get; set; }
        public bool? IsMale { get; set; }
        public DateTime BirthDate { get; set; }
        // other properties ...


        // region non-persistent properties
        public string FullName => $"{FirstName} {LastName}";
    }
}

这只是保持简单还是以这种方式失去了任何有价值的东西？

标签： c#entity-frameworkviewmodeldto

解决方案

我不是在提倡一种特定的方法，只是分享信息......

我不会将您对 FullName 的计算放在 DTO 中。DTO 只是一个简单的对象，实际上更像是一个结构，其中不应该有任何逻辑。DTO 的目的是将数据从一个层/层移动到另一个层，并创建一个间接层，允许您的域模型独立于您的客户端而发展。实体上的全名作为非持久属性在这里比在 DTO 中更有意义。如果您想成为完整的企业，它将在变压器/适配器中。

如果您的项目非常小，并且可能永远不会增长，那么放弃 DTO 是可以接受的。请记住，如果您的项目增长，您可能需要进行一些重构，并且还有其他一些事情需要考虑......

DTO 的另一个好处是将一些数据保留在需要保留的位置。例如，如果您的实体对象中有敏感数据，并且您没有放置一些东西来防止它在 Web 请求中被返回，那么您只是从您的应用服务器层泄露了一些信息（想想您的用户中的密码字段实体）。DTO 要求您考虑向客户端发送/从客户端发送的内容，并使包含数据成为明确的有意行为与无意行为。DTO 还可以更轻松地记录客户请求真正需要的内容。

话虽如此，现在每个 DTO 都是您必须编写和维护的代码，这是避免它们的主要原因，并且模型更改可能会对系统产生明显的连锁反应。

归根结底是决定如何处理潜在的数据泄漏、如何管理客户（如果可以的话）以及模型的复杂程度。

推荐阅读