gpt4 book ai didi

c# - CommandHandler 装饰器依赖

转载 作者:行者123 更新时间:2023-12-02 21:44:00 24 4
gpt4 key购买 nike

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

  1. UpdateUserProfileImageCommandHandlerAuthorizeDecorator
  2. UpdateUserProfileImageCommandHandlerUploadDecorator
  3. 更新UserProfileImageCommandHandler

我的问题在于架构和性能。

UpdateUserCommandHandlerAuthorizeDecorator 调用存储库( Entity Framework )来授权用户。我有其他与此类似的装饰器,它们应该使用和修改实体并将其发送到链上。

UpdateUserCommandHandler 应该将用户保存到数据库中。我目前必须进行另一个存储库调用并更新实体,而我可以从以前的装饰器处理实体。

我的问题是该命令仅接受用户 ID 和一些要更新的属性。如果我从授权装饰器获取用户实体,我如何仍然可以在链上处理该实体?可以将 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();
}
}

最佳答案

您不应该仅仅为了性能而尝试传递任何额外的数据。此外,使用装饰器时,你无法更改契约(Contract)。相反,您应该允许缓存该用户实体,这通常应该是存储库实现的责任。对于 Entity Framework ,这实际上相当简单。您可以调用DbSet.Find(id) EF首先会在缓存中查找实体。这可以防止不必要的数据库往返。我一直这样做。

所以你唯一要做的就是添加 Find(key)GetById映射到 EF 的 Find(key) 的存储库的方法方法,你就完成了。

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

验证授权是一个跨领域的问题,因此将其放在装饰器中似乎没问题,但当前的实现存在一些问题。首先,这样做会导致你有很多非泛型装饰器,从而导致大量的维护工作。此外,如果用户未经授权,您会默默地跳过执行,这通常不是您想要的。

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

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

[PermittedRole(Role.LabManagement)]

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

更新

这是我认为您的 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;
}
}

关于c# - CommandHandler 装饰器依赖,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19890746/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com