CommandHandler装饰器依赖性

Question

我有一个问题，我希望我的处理程序使用从处理程序生成的数据：

1. UpdateUserProfileImageCommandHandlerAuthorizeDecorator
2. UpdateUserProfileImageCommandHandlerUploadDecorator
3. UpdateUserProfileImageCommandHandler

我的问题是体系结构和性能。

UpdateUserCommandHandlerAuthorizeDecorator调用存储库（entityframework）以授权用户。 我还有其他与此类似的装饰器，应该使用和修改实体并将其发送到整个链中。

UpdateUserCommandHandler应该只将用户保存到数据库中。 我现在必须再次调用存储库并更新实体，而我本可以从以前的装饰器处理实体。

我的问题是该命令仅接受用户ID和一些要更新的属性。 如果我从Authorize装饰器获取用户实体，那么我仍如何在链上的那个实体上工作？ 是否可以将该User属性添加到命令中并进行处理？

码：

public class UpdateUserProfileImageCommand : Command
{
    public UpdateUserProfileImageCommand(Guid id, Stream image)
    {
        this.Id = id;
        this.Image = image;
    }

    public Stream Image { get; set; }

    public Uri ImageUri { get; set; }
}

public class UpdateUserProfileImageCommandHandlerAuthorizeDecorator : ICommandHandler<UpdateUserProfileImageCommand>
{
    public void Handle(UpdateUserProfileImageCommand command)
    {
         // I would like to use this entity in `UpdateUserProfileImageCommandHandlerUploadDecorator`
         var user = userRespository.Find(u => u.UserId == command.Id);

         if(userCanModify(user, currentPrincipal))
         {
             decoratedHandler(command);
         }

    }
}

public class UpdateUserProfileImageCommandHandlerUploadDecorator : ICommandHandler<UpdateUserProfileImageCommand>
{
    public void Handle(UpdateUserProfileImageCommand command)
    {
         // Instead of asking for this from the repository again, I'd like to reuse the entity from the previous decorator
         var user = userRespository.Find(u => u.UserId == command.Id);

         fileService.DeleteFile(user.ProfileImageUri);

         var command.ImageUri = fileService.Upload(generatedUri, command.Image);

         decoratedHandler(command);       

    }
}

public class UpdateUserProfileImageCommandHandler : ICommandHandler<UpdateUserProfileImageCommand>
{
    public void Handle(UpdateUserProfileImageCommand command)
    {
         // Again I'm asking for the user...
         var user = userRespository.Find(u => u.UserId == command.Id);

         user.ProfileImageUri = command.ImageUri;     

         // I actually have this in a PostCommit Decorator.
         unitOfWork.Save();
    }
}

Answer 1

您不应仅仅为了性能而尝试传递任何额外的数据。 此外，使用装饰者，您无法更改合同。 相反，您应该允许该用户实体被缓存，并且这通常应该由存储库实现负责。 使用实体框架，这实际上非常简单。 您可以调用DbSet.Find(id)并且EF将首先在缓存中查找实体。 这样可以防止不必要的往返数据库访问。 我一直都这样做。

因此，您唯一要做的就是将一个Find(key)或GetById方法添加到映射到EF的Find(key)方法的存储库中。

此外，我同意皮特的观点。 装饰器应主要用于跨领域的关注。 有时可以在装饰器中添加其他内容，但是您似乎将核心业务逻辑拆分为处理程序及其装饰器。 将文件写到磁盘上需要核心逻辑。 您可能会被视为遵守单一职责，但是在我看来，您将一个职责划分为多个类别。 这并不意味着您的命令处理程序应该很大。 正如Pete所说，您可能希望将其提取到服务中并将该服务注入处理程序中。

验证授权是一个贯穿各领域的问题，因此在装饰器中进行验证似乎还可以，但是当前的实现存在一些问题。 首先，这样做会导致您拥有许多非通用装饰器，从而导致大量维护工作。 此外，如果用户未经授权（通常不是您想要的），您将无提示地跳过执行。

与其默默地跳过，不如考虑抛出异常并阻止用户在正常情况下能够调用此功能。 这意味着，如果引发异常，则说明代码中存在错误，或者用户正在入侵您的系统。 默默地跳过而不会引发异常会使查找错误变得更加困难。

另一件事是，您可能要考虑的是尝试将此授权逻辑实现为通用装饰器。 例如，有一个通用授权装饰器或验证装饰器。 这可能并不总是可能的，但是您可以使用属性标记命令。 例如，在我当前正在使用的系统中，我们将命令标记如下：

[PermittedRole(Role.LabManagement)]

我们有一个AuthorizationVerifierCommandHandlerDecorator<TCommand> ，它检查正在执行的命令的属性并验证是否允许当前用户执行该命令。

UPDATE

这是我认为您的UpdateUserProfileImageCommandHandler可能看起来像的一个示例：

public class UpdateUserProfileImageCommandHandler 
    : ICommandHandler<UpdateUserProfileImageCommand>
{
    private readonly IFileService fileService;

    public UpdateUserProfileImageCommandHandler(IFileService fileService)
    {
        this.fileService = fileService;
    }

    public void Handle(UpdateUserProfileImageCommand command)
    {
         var user = userRespository.GetById(command.Id);

         this.fileService.DeleteFile(user.ProfileImageUri);

         command.ImageUri = this.fileService.Upload(generatedUri, command.Image);

         user.ProfileImageUri = command.ImageUri;     
    }
}

Answer 2

为什么首先要通过装饰器做到这一点？

验证

通常的方法是让客户在提交命令之前进行所有必需的验证。 创建/发布/执行的任何命令都应在提交之前执行所有（合理的）验证。 我之所以加上“合理的”字样，是因为有些事情（例如唯一性）无法事先经过100％验证。 当然，可以在提交命令之前完成执行命令的授权 。

拆分命令处理程序

对于我来说，拥有一个只处理一部分命令处理逻辑然后修饰命令对象的装饰器似乎是过度设计。 恕我直言，装饰器应该用于扩展给定操作的附加功能，例如日志记录，事务或身份验证（尽管就像我说的那样，我认为这不适用于装饰命令处理程序）。

似乎上载图像，然后在数据库中分配新图像URL是一个命令处理程序的责任。 如果要抽象这两个不同操作的详细信息 ，请使用诸如IUserimageUploader类的类注入处理程序。

通常

通常，命令被认为是不可变的，并且一旦创建就不应更改。 这是为了帮助强制命令应预先包含所有必需的信息以完成操作。

Answer 3

我来晚了一点，但是我要做的是定义一个可以IoC注入的IUserContext类。 这样，您可以一次加载重要的用户数据，然后将其缓存，所有其他依赖项可以使用同一实例。 然后，您可以让数据在很长一段时间后过期，并且可以自行处理。