應該在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在洋蔥體系結構和視圖模型中進行此操作，根據我的經驗，它易於管理，更改，為前端或層准備數據，而不是更改核心內容。

如果有人不同意我的意見，請發表評論，我喜歡學習新知識。

希望能幫助到你