代码之家  ›  专栏  ›  技术社区  ›  Marco

ASP.NET MVC ViewModelBuilder建议

  •  8
  • Marco  · 技术社区  · 14 年前

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

    这就是我的代码当前的样子。注意,生成器是通过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>();
        }
    

    任何想法或建议都是很好的!

    3 回复  |  直到 8 年前
        1
  •  1
  •   SDReyes    14 年前

    建筑工人

    我认为您可以将构建正确视图模型的责任转移到构建器。您可以将要构建的ViewModel类型作为参数传递,例如:

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

    关于候选人

    第一步

    上述方法允许您在将在操作内部呈现的视图中具有更大的灵活性(如果控制器应在要显示的3个视图之间进行选择,并且每个视图都有不同的视图模型,会发生什么情况?过滤溶液开始变得复杂。)

    第二选择权

    这个 视图法 我们的责任就是要树立榜样, 渲染视图 使用它。这是 控制器 责任 建立模型 . 因此,作为一个有点正统的,我建议避免将模型构建逻辑放在视图方法中:)。

        2
  •  0
  •   mare    14 年前

    如果你在征求意见,现在看到你的代码,我会投票给你的第一个选择。我已经广泛地使用了动作过滤器,这很好——所有的东西都在一个地方,实现了简单的可装饰动作,等等。

        3
  •  0
  •   Ryan    14 年前

    视图模型操作筛选器可以在视图上下文中查看预期的模型类型,而不是在属性中要求该类型。