5.2 Updating / Manipulating An Entity 更新/使用实体

Updating / Manipulating An Entity 更新/使用实体

Once an entity is created, it is updated/manipulated by the use cases until it is deleted from the system. There can be different types of the use cases directly or indirectly changes an entity.
一个实体一旦被创建，它就会被用例更新/操纵，直到它从系统中被删除。可能有不同类型的用例直接或间接地改变一个实体。

In this section, we will discuss a typical update operation that changes multiple properties of an Issue.
在这一节中，我们将讨论一个典型的更新操作，即修改一个Issue的多个属性。

This time, beginning from the Update DTO: 这次，从更新DTO开始：

By comparing to IssueCreationDto, you see no RepositoryId. Because, our system doesn't allow to move issues across repositories (think as GitHub repositories). Only Title is required and the other properties are optional.
对比IssueCreationDto，你看到没有RepositoryId。因为，我们的系统不允许跨库移动问题（就像GitHub库）。只有Title是必须的，其他的属性是可选的。

Let's see the Update implementation in the IssueAppService: 让我们看看IssueAppService中的更新实现：

• UpdateAsync method gets id as a separate parameter. It is not included in the UpdateIssueDto. This is a design decision that helps ABP to properly define HTTP routes when you auto expose this service as an HTTP API endpoint. So, that's not related to DDD.
• UpdateAsync方法获得Id作为一个单独的参数。它不包括在UpdateIssueDto中。这是一个设计决定，当你将该服务自动暴露为HTTP API端点时，有助于ABP正确定义HTTP路由。所以，这与DDD没有关系。
• It starts by getting the Issue entity from the database.
• 它首先从数据库中获取 Issue实体。
• Uses IssueManager's ChangeTitleAsync instead of directly calling Issue.SetTitle(...). Because we need to implement the duplicate Title check as just done in the Entity Creation. This requires some changes in the Issue and IssueManager classes (will be explained below).
• 使用IssueManager的ChangeTitleAsync，而不是直接调用Issue.SetTitle(..)。因为我们需要实现重复Title的检查，就像刚才在实体创建中做的那样。这需要对Issue和IssueManager类进行一些修改（将在下面解释）。
• Uses IssueManager's AssignToAsync method if the assigned user is being changed with this request.
• 如果指定的用户被改变，则使用IssueManager的AssignToAsync方法。
• Directly sets the Issue.Text since there is no business rule for that. If we need later, we can always refactor.
• 直接设置Issue.Text，因为没有跟它相关的业务规则。如果我们以后需要，我们可以随时重构。
• Saves changes to the database. Again, saving changed entities is a responsibility of the Application Service method that coordinates the business objects and the transaction. If the IssueManager had saved internally in ChangeTitleAsync and AssignToAsync method, there would be double database operation (see the Discussion:Why is the Issue not saved to the database in IssueManager? above).
• 将变化保存到数据库中。同样，保存改变的实体是负责协调业务对象和事务的应用服务方法的职责。如果IssueManager在ChangeTitleAsync和AssignToAsync方法中进行了内部保存，就会有两次数据库操作（见讨论：为什么IssueManager中没有保存到数据库中的操作？）
• Finally uses the IObjectMapper to return an IssueDto that is automatically created by mapping from the updated Issue entity.
• 最后使用IObjectMapper返回一个IssueDto，这个IssueDto是由更新后的 Issue 实体通过映射自动创建的。

As said, we need some changes in the Issue and IssueManager classes.
如前所述，我们需要对Issue和IssueManager类进行一些修改。

First, made SetTitle internal in the Issue class: 首先，在Issue类中将SetTitle设置为内部的：

Then added a new method to the IssueManager to change the Title:
然后给IssueManager添加了一个新的方法来改变Title。