实现领域驱动设计 - 使用ABP框架 - 应用程序服务
应用程序服务
应用程序服务是一种无状态的服务，它实现应用程序的用例。应用程序服务通常获取和返回dto。它由表示层使用。它使用并协调领域对象(实体、存储库等)来实现用例
应用程序服务的常见原则如下:
- 实现特定于当前用例的应用程序逻辑。不要在应用程序服务内部实现核心领域逻辑。我们将回到应用程序领域逻辑之间的差异
- 永远不要为应用程序服务方法获取或返回实体。这打破了领域层的封装。总是获取和返回dto
示例:分配问题给用户
public class IssueAppService : ApplicationService, IIssueAppService
{
//省略了Repository和DomainService的依赖注入
public async Task AssignAsync(IssueAssignDto input)
{
var issue = await _issueRepository.GetAsync(input.IssueId);
var user = await _userRepository.GetAsync(input.UserId);
await _issueManager.AssignToAsync(issue, user);
await _issueRepository.UpdateAsync(issue);
}
}
应用程序服务方法通常有三个步骤,在这里实现了
- 从数据库中获取相关的领域对象来实现用例
- 使用领域对象(领域服务、实体等)执行实际操作
- 更新已更改的实体到数据库中
如果你正在使用EF Core，上面的更新是不必要的，因为它有一个更改跟踪系统。如果你想利用这个EF Core特性，请参阅 关于数据库无关心原则的讨论部分
本例中的 IssueAssignDto 是一个简单的DTO类:
public class IssueAssignDto
{
public Guid IssueId { get; set; }
public Guid UserId { get; set; }
}
数据传输对象(DTO)
DTO是一个简单的对象，用于在应用程序层和表示层之间传输状态(数据)。因此，应用程序服务方法获取和返回dto
通用DTO原则和最佳实践:
- 就其本质而言，DTO应该是可序列化的。因为，大多数时候它是通过网络传输的。因此，它应该有一个无参数(空)构造函数。
- 不应该包含业务逻辑。
- 永远不要继承或引用实体。
输入dto(传递给应用程序服务方法的dto)与输出dto(从应用程序服务方法返回的dto)具有不同的性质。所以，他们会被区别对待
输入DTO最佳实践
不要为输入dto定义未使用的属性
只定义用例所需的属性! 否则，客户端在使用Application Service方法时会感到困惑。您当然可以定义可选属性，但是当客户端提供它们时，它们应该影响用例的工作方式
首先，这条规则似乎没有必要。谁会为方法定义未使用的参数(输入DTO属性)?但是，这种情况会发生，尤其是当您试图重用输入dto时。
不要复用输入dto
为每个用例定义专门的输入DTO(应用程序服务方法)。 否则，某些属性在某些情况下不使用，这违反了上面定义的规则:不要为输入dto定义未使用的属性
有时，为两个用例重用同一个DTO类似乎很有吸引力，因为它们几乎是相同的。即使他们现在是一样的，他们可能会变成不同的时候，你会遇到相同的问题。代码复制是比耦合用例更好的实践
重用输入dto的另一种方法是相互继承dto。虽然这在一些罕见的情况下是有用的，但大多数情况下它会使你达到相同的目的
示例:用户应用服务
public interface IUserAppService : IApplicationService
{
Task CreateAsync(UserDto input);
Task UpdateAsync(UserDto input);
Task ChangePasswordAsync(UserDto input);
}
IUserAppService 在所有方法(用例)中使用 UserDto 作为输入DTO。UserDto的定义如下:
public class UserDto
{
public Guid UserId { get; set; }
public string UserName { get; set; }
public string Email { get; set; }
public string Password { get; set; }
public DateTime CreationTime { get; set; }
}
对于这个示例:
- Id 在创建中不使用，因为服务器会在创建用户时自动生成它
- Password 没有在更新中使用，因为我们有另一个更新密码的方法
- CreationTime 从不被使用，因为我们不能允许客户端发送创建时间。它应该在服务器中设置
真正的实现可以是这样的:
public interface IUserAppService : IApplicationService
{
Task CreateAsync(UserCreationDto input);
Task UpdateAsync(UserUpdateDto input);
Task ChangePasswordAsync(UserChangePasswordDto input);
}
尽管编写了更多的代码，但这是一种更易于维护的方法
例外情况:该规则可能有一些例外:如果您总是希望并行开发两个方法，它们可能共享相同的输入DTO(通过继承或直接重用)。例如，如果您有一个具有一些过滤器的报告页面，并且您有多个Application Service方法(如屏幕报告、excel报告和csv报告方法)使用相同的过滤器但返回不同的结果，您可能希望重用相同的过滤器输入DTO来耦合这些用例。因为，在本例中，无论何时更改过滤器，您都必须对所有方法进行必要的更改，以拥有一致的报告系统。
输入DTO验证逻辑
- 只在DTO内部实现形式验证。使用数据注释验证属性或实现IValidatableObject 进行形式验证。
- 不要执行领域验证。例如，不要尝试检查dto中的唯一用户名约束
示例:使用数据注释属性
public class UserCreationDto
{
[Required]
[StringLength(UserConsts.MaxUserNameLength)]
public string UserName { get; set; }
[Required]
[EmailAddress]
[StringLength(UserConsts.MaxEmailLength)]
public string Email { get; set; }
[Required]
[StringLength(UserConsts.MaxPasswordLength, MinimumLength = UserConsts.MaxMinPasswordLength)]
public string Password { get; set; }
}
ABP框架自动验证输入的dto，抛出AbpValidationException，并在无效输入的情况下向客户端返回HTTP状态400
一些开发人员认为最好将验证规则和DTO类分开。我们认为声明式(数据注释)方法是实用和有用的，并且不会导致任何设计问题。但是，如果您喜欢其他方法，ABP也支持 FluentValidation集成。
有关所有验证选项，请参 阅验证文档。
输出DTO最佳实践
- 保持输出DTO计数最小。在可能的情况下重用(例外:不要将输入dto重用为输出dto)
- 输出dto可以包含比客户端代码中使用的更多的属性。
- 从创建和更新方法返回实体DTO。
这些建议的主要目的是:
-
使客户端代码易于开发和扩展
- 在客户端处理类似但不相同的dto是有问题的
- 将来在UI/客户端上添加其他属性是很常见的。返回实体的所有属性(通过考虑安全性和特权)使客户端代码很容易改进，而不需要接触后端代码
- 如果你将API开放给第三方客户，而你不知道每个客户的需求
-
使服务器端代码易于开发和扩展
- 你需要理解和维护的类更少
- 您可以重用 Entity->DTO 对象映射代码
- 从不同的方法返回相同的类型使创建新方法变得简单明了
示例:从不同的方法返回不同的dto
public interface IUserAppService : IApplicationService
{
UserDto Get(Guid id);
List<UserNameAndEmailDto> GetUserNameAndEmail(Guid id);
List<string> GetRoles(Guid id);
List<UserListDto> GetList();
UserCreationResultDto Create(UserCreationDto input);
UserUpdateResultDto Update(UserUpdateDto input);
}
(我们没有使用异步方法使示例更清晰，但在您的实际应用程序中使用异步!)
上面的示例代码为每个方法返回不同的DTO类型。您可以猜到，在查询数据、将实体映射到dto时，会有很多代码重复
上面的IUserAppService服务可以被简化:
public interface IUserAppService : IApplicationService
{
UserDto Get(Guid id);
List<UserDto> GetList();
UserDto Create(UserCreationDto input);
UserDto Update(UserUpdateDto input);
}
统一使用单个输出DTO:
public class UserDto
{
public Guid Id { get; set; }
public string UserName { get; set; }
public string Email { get; set; }
public DateTime CreationTime { get; set; }
public List<string> Roles { get; set; }
}
- 删除了GetUserNameAndEmail 和 GetRoles，因为Get方法已经返回必要的信息
- GetList 现在与Get返回相同的结果
- 创建和更新也返回相同的UserDto
如前所述，使用相同的输出DTO有许多优点。例如，设想一个场景，您在UI上显示一个Users数据网格。在更新用户之后，您可以获得返回值并在UI上更新它。你不需要再调用GetList。这就是为什么我们建议返回实体DTO(这里是UserDto)作为创建和更新操作的返回值
讨论
有些输出DTO建议可能不适合所有场景。由于性能原因，可以忽略这些建议，特别是当返回的数据集很大，或者当您为自己的UI创建服务时，您有太多的并发请求
在这些情况下，您可能希望创建包含最少信息的专用输出dto。以上建议特别适用于那些维护代码库比忽略不计的性能损失更重要的应用程序
对象映射
当两个对象具有相同或相似的属性时，自动 对象映射 是将值从一个对象复制到另一个对象的有用方法
DTO和实体类通常具有相同/相似的属性，通常需要从实体创建DTO对象。ABP的 对象映射系统 与 AutoMapper 集成使得这些操作比手动映射更容易。
- 只对实体使用自动对象映射来输出DTO映射
- 不要对输入DTO到实体的映射使用自动对象映射。
有一些原因不应该使用输入DTO来进行实体自动映射:
- 实体类通常有一个接受参数并确保有效创建对象的构造函数。自动对象映射操作通常需要一个空的构造函数
- 大多数实体属性将具有私有设置器，您应该使用方法以可控的方式更改这些属性
- 您通常需要仔细地验证和处理用户/客户端输入，而不是盲目地映射到实体属性
虽然其中一些问题可以通过映射配置来解决(例如，AutoMapper允许定义自定义映射规则)，但它使您的业务代码隐式/隐藏，并与基础设施紧密耦合。我们认为业务代码应该是明确的、清晰的和容易理解的
请参阅下面的 创建实体 一节，以获得本节建议的示例实现。
