Question

让我们假设我们有一个控制器，其中包含一些行为，如下所示：

    [HttpPost, Authorize]
    public ActionResult Update(Guid itemId)
    {
        var item  = repository.GetById(itemId);
        if (item == null)
            return NotFoundResult();

        //Do something with item

        return View();
    }

我们已经应用了Authorize属性，以确保只有某些特定用户可以执行我们的操作。

我们还可以移动以下块

        var item  = repository.GetById(itemId);
        if (item == null)
            return NotFoundResult();

到另一个属性并将其应用于我们的操作。

还有另外一些行动，我们可以提取一些特定的逻辑属性，并将它们一次又一次地应用到我们的行动中。

我的问题出现了：我们何时应该这样做，何时不应该这样做？将这种逻辑移动到动作方法属性实际上是一件好事吗？

我在审查某个项目的单元测试时遇到了这个问题。我实际上是在寻找代码文档，如果没有找到例如找不到项目的控制器操作那么我很难看到它。我在属性单元测试中找到了这个部分，但这实际上是属性的责任吗？

我可以理解授权属性，它实际上是另一层，但是我上面描述的逻辑怎么样？控制器的行动责任是与它一起工作还是......？

提前感谢任何评论：）

Answer 1

如果要为一组操作运行这样的逻辑，可以覆盖OnActionExecuting方法来执行检查。

创建属性很困难，因为您还需要创建一个基本控制器并编写一些反射代码来检查操作方法以查看该属性是否存在，然后对其进行操作。

protected override void OnActionExecuting(ActionExecutingContext ctx) 
{
    if(!ctx.ActionDescriptor.ActionName.StartsWith("Create"))
    {
        var item  = repository.GetById(itemId);
        if (item == null)
            ctx.Result = NotFoundResult();
    }
}

Answer 2

属性用于ASP.net MVC中的各种事物（例如过滤或异常处理）。但是，我不会将这样的逻辑移动到属性，因为这是您正在执行的操作的基本逻辑。将此代码移动到属性只会使查找操作实际执行的操作变得更加困难。

ASP.NET MVC：控制器动作逻辑的哪一部分应该/不应该移动到属性？

2 个答案: