Question

对于除了普通视图模型之外的任何东西，我使用视图模型构建器来处理生成视图模型对象的责任。现在，我使用构造函数注入构建器到我的控制器中，但这有点气味，因为构建器实际上依赖于正在执行的操作方法。我有两个想法。第一个涉及自定义ActionFilter，允许我使用适当的构建器来装饰每个操作方法。第二种方法是添加View方法的覆盖，该方法可以接受通用。

这就是我的代码目前的样子。注意，构建器通过ctor注入。

    [HttpGet, ImportModelStateFromTempData, Compress]
    public ActionResult MyAccount()
    {
        return View(accountBuilder.Build());
    }

以下是一个选项：

    [HttpGet, ImportModelStateFromTempData, Compress, ViewModelBuilder(typeof(IMyAccountViewModelBuilder)]
    public ActionResult MyAccount()
    {
        return View();
    }

或选项二：

    [HttpGet, ImportModelStateFromTempData, Compress]
    public ActionResult MyAccount()
    {
        return View<IMyAccountViewModelBuilder>();
    }

任何想法或建议都会很棒！

Answer 1

TheBuilder

我认为您可以将构建正确视图模型的责任移交给构建器。并且您可以将要构建的ViewModel类型作为参数传递，例如：

[HttpGet, ImportModelStateFromTempData, Compress]
public ActionResult MyAccount()
{
   return View( AccountBuilder.Build<MyAccountViewModel>( ) );
}

关于候选人

FirstOptionThis

上述方法允许您在操作中呈现的视图中具有更大的灵活性（如果您的控制器应该在3个视图之间进行选择以显示，并且每个视图都有不同的视图模型，会发生什么？过滤器解决方案开始变得复杂。）

SecondOption

查看方法的责任是使用模型并使用呈现视图。这是控制器对构建模型的责任。所以做一点正统，我建议避免在View方法中放置模型构建逻辑：）。

Answer 2

如果您要求提供意见，现在看到您的代码，我会投票给您的第一个选项。我已经广泛使用了动作过滤器并且它很好 - 一切都在一个地方，可以轻松地进行可装饰的操作等。

Answer 3

您的视图模型操作过滤器可以查看ViewContext上的预期模型类型，而不是在属性中要求它。

ASP.NET MVC ViewModelBuilder建议

3 个答案:

TheBuilder

关于候选人

FirstOptionThis

SecondOption