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

---

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

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

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

如果您的项目非常小，并且可能永远不会增长，那么放弃DTO是可以接受的。请记住，如果你的项目增长了，你可能需要做一些重构，还有一些其他的事情要考虑…… DTO的另一个好处是将一些数据保留在需要保留的地方。例如，如果您的实体对象中有敏感数据，并且您没有放置一些东西来防止在web请求中返回这些数据，那么您只是从应用程序服务器层泄漏了一些信息（想想您的用户实体中的密码字段）。DTO要求您考虑向客户机发送或从客户机发送什么，并使包含数据成为明确的有意行为，而不是无意行为。DTO还可以更轻松地记录客户端请求真正需要的内容

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

---

归根结底，要决定如何处理潜在的数据泄漏，如何管理客户机（如果可以的话），以及模型可能会变得多么复杂。

当然，将所有方法放在一个地方是好的，但我想这会混淆持久性。这完全取决于您如何读取数据和持久化数据。我应该在问题中提供哪些其他信息？如果您这样做，您需要在fluent配置中将非持久化属性标记为

[NotMapped（）]

或

.Ingore（）

。您将无法在LINQ查询中查询这些属性。@DavidBrowne Microsoft不会自动忽略只读属性吗？@roozbehS我不知道，但如果这样做了会有意义的。谢谢您的回答。我的项目是winform，所以我想没有必要担心数据泄漏。我说的对吗？可能不对，除非您正在从进程外或客户端发送/接收数据。