MediaTR-将命令/查询用作参数来控制器操作

发布于 2025-02-04 16:29:57 字数 932 浏览 4 评论 0原文

我正在使用C#MediaTR库来实现调解器模式,以从控制器中发送命令和查询。由于我是这种模式的新手,所以我一直在观看一些在线教程,在某些情况下,我看到了Mediator QUERY命令类作为参数传递给Controller Action的参数方法并将其转发到媒体TR,而在某些教程中,有一个单独的视图模型传递到Controller Action方法方法中,该模型首先映射到命令或查询类,然后转发到MediaTR。

哪种方法被认为更好,将命令/查询传递给控制器​​操作或使用视图模型?还找不到任何相关答案。任何帮助都是高度认可的

命令被传递到控制器操作参数

    [HttpPost]
    public async Task<IActionResult> Login(LoginUserCommand loginUserCommand)
    {
        var User = await _meditr.Send(loginUserCommand);

        return View();
    }    

viewmodem

    [HttpPost]
    public async Task<IActionResult> Login(LoginViewModel loginViewModel)
    {
        var authenticateUserCommand = _mapper.Map<LoginUserCommand>(loginViewModel);
        var User = await _meditr.Send(authenticateUserCommand);

        return View();
    }

I am using the C# MediatR library to implement a mediator pattern to send commands and queries from my controller. As I am new to this pattern so I have been watching some online tutorials where I saw that in some cases the Mediator Query or Command classes have been passed as parameters to controller action methods and forwarded as it is to the MediatR while in some tutorials there is a separate view model passed into the controller action methods method, which is first mapped to command or query class and then forwarded to the MediatR.
Which approach is considered better, passing Command/Query to controller action directly or using a view model instead? Couldn't find any relevant answer yet. Any help is highly appeciated

Command being passed into controller action parameter

    [HttpPost]
    public async Task<IActionResult> Login(LoginUserCommand loginUserCommand)
    {
        var User = await _meditr.Send(loginUserCommand);

        return View();
    }    

ViewModel used in the controlleraction parameter

    [HttpPost]
    public async Task<IActionResult> Login(LoginViewModel loginViewModel)
    {
        var authenticateUserCommand = _mapper.Map<LoginUserCommand>(loginViewModel);
        var User = await _meditr.Send(authenticateUserCommand);

        return View();
    }

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

幸福丶如此 2025-02-11 16:29:57

我认为您应该首先了解viewModeldto之间的区别。在大多数情况下,命名是错误的。从技术上讲,在此上下文中的命令是dto。但这也代表了在业务领域中具有特殊含义的东西 - 将会发生的事情,即要在系统中执行的命令。

阅读这篇文章以更好地理解:
视图模型和数据传输对象之间有什么区别?

但是,当您使用Media 。
实际上,您的控制器仅充当用户和程序逻辑之间的接口或桥梁,
而且只需要建立此连接,因此它接收所需的命令或dto,并且验证操作为
命令处理程序的责任。在这种情况下,如果您以不同的方式收到数据并将其映射到命令,
它实际上是无用的,并且被认为是加班,因为您不会在控制器上进行任何验证。

这是一个更好的选择

[HttpPost]
public async Task<IActionResult> Login(LoginUserCommand loginUserCommand)
{
    var User = await _meditr.Send(loginUserCommand);
    return View();
}   

因此,如果您正在寻找一个很好的例子,

,我建议使用此存储库: https:// github。 com/jasontaylordev/cleanarchitecture

I think you should first understand the difference between ViewModel and DTO. In most cases, the naming is wrong. A command in this context is technically a DTO. But it also represents something that has a special meaning in the business domain - something that shall happen, i.e. a command to be executed in the system.

Read this post to better understand :
what is the difference between a view model and a data transfer object?

But about your main question When you use Mediatr.
In fact, your controller only acts as an interface or bridge between the user and the program logic,
and only needs to establish this connection, so it receives the desired command or Dto, and the validation operation is
the responsibility of your command and handler. In this scenario, if you receive the data in a different way and map it to a command,
it is practically of no use and is considered overtime because you are not going to do any validation on your controller.

So this is a better option

[HttpPost]
public async Task<IActionResult> Login(LoginUserCommand loginUserCommand)
{
    var User = await _meditr.Send(loginUserCommand);
    return View();
}   

If you are looking for a good example, I recommend this repository :

https://github.com/jasontaylordev/CleanArchitecture

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文