MVC，强类型的浏览VS关注点分离

控制器：

[HttpPost] 
public ViewResult RsvpForm(GuestResponse guestResponse) 
{ 
    // TODO: Email guestResponse to the part organizer 
    return View("Thanks", guestResponse); 
}

查看：

@model MvcApplication1.Models.GuestResponse 
@{ 
    ViewBag.Title = "Thanks"; 
} 
<div> 
    <h1>Thank you, @Model.Name!</h1> 

    @if (Model.WillAttend == true) 
    { 
     @:It's great that you're coming. The drinks are already in the fridge! 
    } 
    else 
    { 
     @:Sorry to hear that you can't make it, but thanks for letting us know. 
    } 
</div>

我认为，这方法违背分离视图和模型/控制器逻辑的概念。

我的做法是：

控制器：

[HttpPost] 
    public ViewResult RsvpForm(GuestResponse guestResponse) 
    { 
     ViewResult v = View("Thanks"); 
     v.ViewBag.Name = guestResponse.Name; 

     if (guestResponse.WillAttend) 
     { 
      v.ViewBag.Message = "It's great that you're coming. The drinks are already in the fridge!"; 
     } 
     else 
     { 
      v.ViewBag.Message = "Sorry to hear that you can't make it, but thanks for letting us know."; 
     } 

     return v; 
    }

查看：

@{ 
    ViewBag.Title = "Thanks"; 
} 
<div> 
    <h1>Thank you, @ViewBag.Name!</h1> 

    @ViewBag.Message; 

</div>

的这个 “问题” 的目的是为了阐明这个观点应该用于查看和控制器来控制要显示的内容，并且书中的例子是“坏方法”（我是缺点因为作者只是想展示MVC的能力）

现在正在使用强类型视图（与逻辑代码）真的这个好主意，还是回到ASP意大利面代码？

请给一些很好的反馈考虑到高品质的企业设计

更新： 我知道这是简单的例子，有没有验证ANS这样，但是这将是一个很好的做法（在这个例子的目的）把逻辑模型，然后在视图刚刚访问喜欢的结果：

@Model.Message

来源

2013-01-21 Pawel Cioch

如果我会阅读更多的章节，我会得到答案。我很不耐烦。 “ ”视图包含向用户显示模型元素所需的逻辑，仅此而已。“ 感谢大家的反馈 –

谁拥有这些权利，可以将此问题标记为已关闭/已回答/已删除 –

使用代码中的观点是不一样的东西具有强类型的意见。你可以很容易地没有其他的。强烈的类型意见有几个优点，本身并不是违反关注点分离。

在视图中使用分支代码可能是一种代码异味，实际上可能违反了关注点的分离，但这实际上取决于代码试图执行的操作。在你提交的情况下，我会争辩说这不是违规行为，因为视图中使用的字符串严格地用于演示目的。

来源

2013-01-21 22:46:30 PinnyM

分离问题不是关于耦合本身，而是描述谁对什么负责。在控制器中创建UI元素违反了关注点的分离，填充数据不会。必要的是，控制器和视图之间需要一些耦合。在所有控制器动作必须提供视图用于生成UI的数据之后。通常，我喜欢在做MVC时强类型视图和每个视图模型。这给了我在我的视图代码中强类型数据的好处。在实践中，通常会混合使用强类型视图模型和一些ViewBag数据，以解决横切问题。

至于在视图中使用逻辑，我会说“这取决于”。我使用了单独的视图，一个可以在几个部分（基于模型数据）之间进行选择的视图，通过控制流来选择HTML变体。选择哪种方法取决于模型/视图之间的差异程度。如果逻辑只是围绕着选择UI显示，我很乐意将它放在视图中。我宁愿有这些，然后推回到控制器的选择。这会违反顾虑的分离。

来源

2013-01-21 22:46:50 tvanfosson

随着tvanfosson简洁地解释，分离问题来自Controller和View的解耦。与面向Web表单和asp classic相反，MVC体系结构将逻辑层（Controller）与表示层（View）分隔开来。只要每个代码位于不同的位置，我们就可以实现问题分离。

该模型是用于从分离图层传递信息的被动介质。使强制类型的模型收紧2之间的“契约”，但不违反分离。您的数据访问方法可以从ADO发展到ORM，而无需重新访问查看代码。您的ORM可以重构为使用Web服务，而无需更改视图。

只有当您决定更改视图的传入或传出值时，您才需要更改视图。而且，核心是分离关注。

来源

2013-01-21 23:14:04

MVC，强类型的浏览VS关注点分离

回答

相关问题