应该在DTO模型还是在目标实体模型中执行计算？

Question

我目前正在ASP.NET Core 2.2中创建各种实体，并附带用于Web API的DTO。 客户端应用程序将向相关的控制器操作提交DTO对象。 在那里使用AutoMapper，它将从DTO对象映射到实体对象。 生成的实体对象将保存到一个实体框架存储库，该存储库此时将是Microsoft SQL数据库。 为简便起见，我们假设在这种情况下时区是不相关的。

我只是想知道哪种方法更合适，或者甚至不在DTO或Entity中但可能在Controller动作中都没有计算。

注意：实际代码更复杂，并且涉及各种属性的各种计算，我仅选择一个简单的案例来说明我的问题。

方法1

// Entity
public class EventTimes
{
    public DateTime Start { get; set; }
    public DateTime End { get; set; }
    public decimal TotalHours => (decimal)(End - Start).TotalHours;
}

// DTO
public class EventTimesDto
{
    public DateTime Start { get; set; }
    public DateTime End { get; set; }
}

方法＃2

// Entity
public class EventTimes
{
    public DateTime Start { get; set; }
    public DateTime End { get; set; }
    public decimal TotalHours { get; set; }
}

// DTO
public class EventTimesDto
{
    public DateTime Start { get; set; }
    public DateTime End { get; set; }
    public decimal TotalHours => (decimal)(End - Start).TotalHours;
}

Answer 1

这取决于实际情况。 EventTimes是实体还是它是域模型的一部分？

无论哪种方式，我都不会将其放在dto中，因为这实际上只是用于传输数据，因此它不应包含任何逻辑（可能还包括验证）。

由于此计算的职责既不是dto的一部分，也不是实体模型的职责，因此您可以将繁重的计算放入EventTimesCalculator ，如下所示：

public class EventTimesCalculator
{
    public decimal CalculateTotalHours(EventTimes eventTimes)
    {
        return (decimal)(eventTimes.End - eventTimes.Start).TotalHours;
    }
}

如果EventTimes是您的业务层/域模型的一部分，则更合适的方法是在模型内部使用GetTotalHours()方法而不是属性。 当然，如果要保存该信息，则需要将其映射到持久性模型。 再说一次，由于可以计算出此信息，因此根本不需要保留它，主要是因为逻辑可能会更改（例如：排除中断，中断等）。

我的建议是停止对数据库实体的思考（我假设您在上文中已经说过）。

最后，它是放置计算逻辑的一个细节，更重要的是要有一个简单的设计。 是应用程序整体式地将逻辑放在包含业务逻辑的层中。 它是一个分布式体系结构，在负责Eventing的服务中处理模型的计算。 它只是一个小的API，请保持简单，将其放在您或您的团队最期望的位置。

Answer 2

我使用第二种方法，因为实体可以包含可以由应用程序流程修改的原始数据。

通用模式数据传输对象（DTO）正是您想要在应用程序层之间传输数据的对象 ，可以将数据转换为所需的输出。 Dto不能包含业务逻辑，但也可以“准备”，“减少”目的地需要的数据。

例如：
如果表示层需要totalHours Iam，则在模型中而不是实体中执行此操作。 整体执行此操作将导致无休止的修改。

另一个示例可以是用户的全名Firstname ， Lastname ， AcademicDegree 。

实体可以容纳所有人，但

• 一个演示文稿需要[学历] [名字] [姓氏]和
• 第二需求数据采用不同格式，例如[姓氏] [名字] [学历]。

好的保持属性可以在特定的DTO中代替实体恕我直言，从而形成所需的格式。

我使用ASP.NET Core在洋葱体系结构和视图模型中进行此操作，根据我的经验，它易于管理，更改，为前端或层准备数据，而不是更改核心内容。

如果有人不同意我的意见，请发表评论，我喜欢学习新知识。

希望能帮助到你