Question

阅读有关CQS原则的人知道：

CQS声明每种方法都应该要么是执行一个的命令操作或返回数据的查询给来电者，但不是两者。

说到ASP.NET MVC操作，CQS是否表明我们不应该有这样的Action？

public PartialView InsertOrder(Order order)
{
       OrderService.InsertOrder(order);
       return PartialView("OrderDetails", order);
}

此方法正在更改系统状态并返回当前状态。如果在这里应用CQS，我们应该有两个单独的操作：一个用于插入新订单，一个用于获取系统系统（如果第一个Action成功完成，应该从客户端调用）。但是，这使编程变得复杂。

我想知道你对此的看法。

MOSH

Answer 1

网络上命令/查询分离的一个常见示例是Post/Redirect/Get。

在ASP.NET MVC中，这通常以最简单的方式实现，如

[HttpPost]
public ActionResult UpdateOrder(Order order){
  UpdateOrder(order);
  return RedirectToAction("ViewOrder", new { order.OrderId });
}

[HttpGet]
public ActionResult ViewOrder(int orderId){
  return View(GetOrder(orderId));
}

对于AJAX和部分视图，此可能不是最佳策略，因为Post / Redirect / Get解决的问题并不真正相关，并且重定向可能很棘手。

Answer 2

CQS仅关注对同一对象的命令和查询。由于OrderView订单不是同一个对象（我猜你的实现），原则不适用，所以你的代码不反对原则，也不赞成：）

Answer 3

我从来没有听说过CQS，但是如果你正在做ASP.NET MVC（MVC模式），你写的动作就完全没问题了（假设这个OrderService有一个真实服务的抽象）。控制器操纵模型并决定渲染哪个视图并将此模型传递给视图。

Answer 4

我对埃菲尔时代的这个术语有一个模糊的回忆（如果一直追随，实际上早于大多数当前的oop原则已经过了十年左右的时间（我认为是80年代后期）。我建议这个术语和/或原则现在可能已经过时，并且被mvc中的行动结果所取代（如asp或codeignitor等等）。我实际上认为就定义而言（我现在只是查看），这种分离与在你的例子中执行动作即OrderService.InsertOrder(order)的逻辑。所以，在某种程度上，在你的动作中执行的mvc实际上是遵循这种模式的loosley（InsertOrder不会尝试呈现任何有状态信息，纯粹处理订单对象）。

我建议您查看asp.net mvc的最佳实践，该实践基于返回actionresult（或部分，contentresult等等）。这种模式旨在简化范式，以统一和普遍接受的方式促进生产力。

当然，您可以使用操作返回值为插入/更新/删除方案生成成功或失败，然后根据这些返回值请求部分视图。但是，我个人认为我不会从这种方法中获得太多的价值，因为MVC中的控制器关注的是如何通过操作来挽回视图应该返回的逻辑。

希望这会有所帮助

吉姆

CQS和ASP.NET MVC操作

4 个答案: