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

Question

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

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}";
    }
}

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

Answer 1

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

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

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

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

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

这归结为决定您希望如何处理潜在的数据泄漏、您希望如何管理您的客户（如果可以的话）以及您的模型可能变得多复杂。