如何使用 MVC 避免标签汤？

Question

我读这篇文章是为了证明 MVC 相对于非 MVC（如常规旧 php）的合理性（不使用 MVC，甚至可以使用经典的 asp，尽管很痛苦）：

http://www.codinghorror.com/blog/2008/07/web-development-as-tag-soup.html

我找不到答案。我认为获得标签汤是不可避免的。是的，我知道 MVC 将模型和控制器分开，但是当你到达视图时，一切都变得丑陋了。我可以读取发出的 html，与标签汤一样好甚至更好。

我不会使用单元测试，所以这并不是一个重要的优势。我不知道如何才能避免丑陋的视图，现在无论我如何让它枯萎 mvc 或只是发出 html。

我认为使用所有奇怪的编码（而且它就是代码）来维护视图并不比使用 response.write "" 更容易。

：处理 ASP.NET MVC“标签汤”

示例 作者：Arnis（无意冒犯他或其他任何人），修复了问题中可怕的代码，但对我来说，这仍然看起来很糟糕，或者至少不是我所期望的。对我来说，这些尖括号也可能是 <% %> 或 。

我喜欢像 codeigniter 这样的东西，它确实是我见过的最干净的，但它仍然不是我所期望的。我想我希望 MVC 中存在一些魔力，让一切变得美丽。显然，除非一个人真的非常小心，否则没有比使用经典 asp 更好的了，因为它与视图相关。

这主要是关于视图。不是关于哪种语言更适合什么或谁的模板引擎是最好的（它们都有相同的标记混合倾向）。

相信我。我希望让 MVC 与我的合作开发人员一起工作，所以我根本不反对将它作为一种范例。我不能仅仅因为每个人都在做某件事或类似的事情就让他们同意某件事。

感谢您的任何评论。我必须能够证明这些事情的合理性，虽然我了解 MVC 和我所得到的东西，但这种观点让很多事情看起来像是浪费时间。

编辑：一切似乎都是针对特定的框架而不是计划。我看到了一些见解，但最终似乎除了纪律之外别无他法。谢谢大家的回答。

Answer 1

看看如何使用 Razor 视图引擎，包含在 MVC 3 中。还要尝试将所有逻辑保留在 Controller 类中，并根据 View 中显示的内容构建模型。

• Razor 是避免标签混乱的一种明显方法，因为不需要任何 <% 和 %> 标签 - 只需一个@ 在代码之前，视图引擎会计算出 C# 结束位置和 HTML 开始位置。

  @Model.Name;
  

  即使是循环和 if 语句在使用 Razor 和神奇的 @ 字符的 .cshtml 文件中看起来仍然很性感。

  @if(shouldDisplayDiv) {
      
  显示 Div！
  }
  
  
  @foreach(Model.Friends 中的用户 user) {
      
  }
  

  默认情况下，Razor 还会为您处理 HTML 编码，因此您的视图不会充满 Html.Encode 调用。 （注意：如果您需要输出 HTML，您可以使用 Html.Raw 辅助方法）。

• 将逻辑放入控制器 理想情况下将消除视图中对大代码块的需要。尝试让模型对象包含视图的所有动态数据，就像视图中显示的那样。目标是在您的视图中完全没有任何 C# 代码（毫无意义，但如果这是目标，看看您能达到多接近它！）。

• 部分视图可以很好地分隔视图的不同部分（但尽量不要使用它们太多）。您还可以将不同的模型对象传递给每个部分视图，我发现这对于一些大循环或类似 flair< /a>.

• HTML 助手也非常有用（感谢 subkamran）。这里与上面提到的分部视图有类似的概念，但 HtmlHelpers 略有不同，因为您指定方法的参数（及其类型），这与您可以传递单个 Model 对象的分部视图相反。这是一个 如何实现它们的好例子。同样，这些在您的 cshtml 代码中看起来非常整洁。

   
  @Html.SomeMethod(Model, "String", 5)
  ;
  

• 客户端 MVC 是另一种选择，如果您正在开发 AJAX 密集型 Web 应用程序，这是一个强烈的建议。按照控制器中的逻辑，您将使用诸如 Backbone.js 之类的客户端 MVC 框架以整洁的方式对 HTML 进行模板化，并使用 jQuery .ajax( ) 与您的控制器来回交谈。这是分离表示层的绝佳实践，为您留下一些漂亮的视图标记！

我坚持这些小准则，它对我来说就像一种魅力。漂亮、干净的 HTML 标记，偶尔带有 @ 字符。非常容易维护（至少视图是！）。

编辑：请注意，所有这些要点都包含在 ASP.NET MVC 3 中，并且就 Microsoft 而言都是“最佳实践”。无需安装任何额外的框架、插件或插件即可遵守这些准则。

Answer 2

MVC 受到关注是有原因的。虽然视图中确实添加了一些标签，但如果逻辑在其所属的控制器中正确处理，那么它会更清晰。

了解 MVC 的真正含义也很重要： http://en.wikipedia.org/wiki /模型-视图-控制器。您从中获得的优点是更干净的分离和易于替换。

考虑一下这一点。您有一位客户希望您编写一个同时支持传统浏览器和移动浏览器的应用程序。使用 MVC 模式，让控制器检测平台并更改呈现的视图非常容易。如果操作正确，将一个视图替换为另一个视图应该是一个非常简单的过程。

我有 7 年在 ASP.NET Forms 中编写应用程序的经验。一旦我切换到 MVC 并开始理解 MVC，我就意识到我再也不会回去了。视图更清晰，调试更简单，逻辑更明显。我编写的最后一个应用程序使用 MVC 和 jQuery，每天有 3000 个用户，并且已成为我们现在编写的所有网站的模型网站。

我们的客户要求我们为我们的网站添加移动支持。因为我们在实现中选择了MVC，所以我们花了1周的时间才添加对移动设备的全面支持。如果我们在 ASP.NET 表单中完成此操作，我们不可能如此快速地完成此操作并如此有效地利用代码。

虽然示例代码来自 http://www. codinghorror.com/blog/2008/07/web-development-as-tag-soup.html 看起来确实很糟糕，你看过 ASP.NET GridView 吗？ HTML 太糟糕了。您提供的示例还显示有人可以做一些工作来清理他们的观点。以下是 gridview 与带有 Razor 的 MVC 的比较：

GridView：

<asp:datagrid id="voucherGrid" runat="server" CssClass="dg" CellPadding="2" AutoGenerateColumns="False" DataKeyField="cx_nbr" 
        Width="800px" AllowPaging="True" AllowSorting="True" PageSize="20" OnPageIndexChanged="voucherGrid_PageIndexChanged" 
        OnSortCommand="voucherGrid_SortCommand" OnItemDataBound="voucherGrid_ItemDataBound">
        <SelectedItemStyle CssClass="dgSelectItem"></SelectedItemStyle>
        <AlternatingItemStyle CssClass="dgAlternateItem"></AlternatingItemStyle>
        <ItemStyle CssClass="dgNormalItem"></ItemStyle>
        <HeaderStyle ForeColor="White" CssClass="dgHeader"></HeaderStyle>

        <Columns>
            <asp:TemplateColumn HeaderText="Image">
                <ItemStyle HorizontalAlign="Center"></ItemStyle>
                <ItemTemplate>
                    <asp:HyperLink id="voucherImageLink" Target="_blank" runat="server">Image</asp:HyperLink>                                               
                </ItemTemplate>
            </asp:TemplateColumn>
            <asp:BoundColumn DataField="cx_voucher_nbr" SortExpression="cx_voucher_nbr" HeaderText="Call #">
                <ItemStyle HorizontalAlign="Center"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_pkup_datetime" SortExpression="cx_pkup_datetime" HeaderText="Date" DataFormatString="{0:MM/dd/yyyy}">
                <ItemStyle HorizontalAlign="Center"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_pass_name" SortExpression="cx_pass_name" HeaderText="Passenger">
                <ItemStyle Wrap="False"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_pkup_address" SortExpression="cx_pkup_address" HeaderText="Pick-Up">
                <ItemStyle Wrap="False"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_dest_address" SortExpression="cx_dest_address" HeaderText="Destination">
                <ItemStyle Wrap="False"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_trip_miles" SortExpression="cx_trip_miles" HeaderText="Miles" DataFormatString="{0:N2}">
                <ItemStyle HorizontalAlign="Right"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_pkup_datetime" SortExpression="cx_pkup_datetime" HeaderText="Time" DataFormatString="{0:t}">
                <ItemStyle HorizontalAlign="Center"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_vch_wait_time_amt" SortExpression="cx_vch_wait_time_amt" HeaderText="Wait" DataFormatString="{0:C}">
                <ItemStyle HorizontalAlign="Right"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_vch_other_amt" SortExpression="cx_vch_other_amt" HeaderText="Other" DataFormatString="{0:C}">
                <ItemStyle HorizontalAlign="Right"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_vch_admin_charge_amt" SortExpression="cx_vch_admin_charge_amt" HeaderText="Admin Charge" DataFormatString="{0:C}">
                <ItemStyle HorizontalAlign="Right"></ItemStyle>
            </asp:BoundColumn>
            <asp:BoundColumn DataField="cx_vch_fare_amt" SortExpression="cx_vch_fare_amt" HeaderText="Rate" DataFormatString="{0:C}">
                <ItemStyle HorizontalAlign="Right"></ItemStyle>
            </asp:BoundColumn>
        </Columns>

        <PagerStyle ForeColor="White" CssClass="dgPager" Mode="NumericPages"></PagerStyle>
    </asp:datagrid>

Razor：

<table id="voucherGrid" class="dg" style="width: 800px;">
   <th class="dgHeader">
      <td>Image</td>
      <td>Call #</td>
      <td>Date</td>
      <td>Passenger</td>
      <td>Pick-Up</td>
      <td>Destination</td>
      <td>Miles</td>
      <td>Time</td>
      <td>Wait</td>
      <td>Other</td>
      <td>Admin Charge</td>
      <td>Rate</td>
   </th>
   @foreach(var voucher in Model.Vouchers) {
   <tr>
      <td>@voucher.Image</td>
      <td>@voucher.CallNum</td>
      <td>@voucher.Date</td>
      <td>@voucher.Passenger</td>
      <td>@voucher.PickUp</td>
      <td>@voucher.Destination</td>
      <td>@voucher.Miles</td>
      <td>@voucher.Time</td>
      <td>@voucher.Wait</td>
      <td>@voucher.Other</td>
      <td>@voucher.AdminCharge</td>
      <td>@voucher.Rate</td>
   </tr>
   }
</table>

你告诉我哪个看起来更容易理解？对我来说，处理 html 标签和一些额外的 @ 或 <% 标签要干净得多。

您还提到不需要进行单元测试。我会重新考虑这个想法。单元测试对于在生产站点上发生问题之前发现问题非常有用。

Answer 3

那里又回来了。一次又一次。原始 HTML。梦衣者。 ASP。微软Word。 ASP.NET、MVC.NET。我们似乎能够触及光谱的两端，但中间没有最佳位置。

归根结底，我们最希望说的是“好吧，至少所有的疯狂都被隔离在视野中”。我说“希望”是因为根据我的经验，说“面向对象”比用 OO 所暗示的所有软件原则优点来实现面向对象要容易得多。

从长远来看，标签汤不是问题。这绝对不是 MVC 上下文中的问题。问题在于令人震惊的编码。 MVC 部分像连体三胞胎一样融合在一起，清楚地表明软件设计和编码原则方面的无能，这是迄今为止更大的犯罪。

在 MVC 范式中编码时，像 Ruby on Rails 或 MVC.NET 这样的 MVC 框架将有助于提高编码效率；它本身并不会让你编码得更快。如果您不知道自己在做什么，那么它肯定不会阻止代码维护的噩梦。

Answer 4

1. 使用razr视图引擎（我的偏好，我认为它看起来更整洁）。 response.write "" 很容易编写。但是您是否在仅控制视图并且可以轻松交换或更改而无需触及任何服务逻辑的文件/类中执行此操作？这让我想到了#2。


2. 与您的团队讨论关注点分离并决定每个逻辑片段的位置。依赖接触点在哪里，您的所有逻辑是否都集中在 DLL 中，而对视图/控制器一无所知？从一开始就决定并把它写在某个地方。
3. 将观点保留为观点！
4. 不要在视图中执行任何操作！
5. 一旦您到达视图，您就只是在观看！
6. 我有没有提到过观点就是这样？

我不会嫉妒任何人使用 MVP 或任何其他范例。但是，如果您想尝试 MVC，请正确执行，您会发现重构和维护代码变得更加容易。

我的2分钱

Answer 5

视图层相对于标签汤的优点在于，视图层应该将不良逻辑与不良数据隔离开来，从而更容易追踪根本原因。这不会自动发生，它必须被纳入视图的代码约束中。我见过的关于使用 MVC 的 HTML 视图的最佳方法如下（来自 Tony Marston )：

• 将数据转换为HTML的代码是显示逻辑。
• 创建或获取随后转换为 HTML 的数据的代码不是显示逻辑。

了解是成功的一半，一致的执行是另一半。能力越大，责任越大，因此使用有限的命令子集有助于强制执行更简洁的代码。最少的声明将被打印并包括在内。用于生成表、列表或表单的循环和数据绑定可以由 JavaScript 库或 XSLT 处理。变量赋值、条件逻辑和字符串操作可以在本地或全局包含中完成。其他任何事情都可以由模型或控制器处理。

Answer 6

不要在模板代码中进行任何计算。

看看 Django 中允许的内容： https://docs.djangoproject.com/ en/1.3/topics/templates/

没有算术。不向方法传递参数。没有任何类型的定义（循环除外）。这迫使您在视图方法中执行几乎所有操作，并传入所需的任何对象和列表，从而保持干净。

Answer 7

您可以使用 GWT、ZK、Vaadin、JSF 2 或隐藏 HTML 的东西。我不知道你说的MVC是什么意思。 Django/RoR/CakePHP 模型-视图-呈现器模式有时称为 MVC 或真正的 MVC。如果您坚持使用 MVC，您的视图代码中应该只有数据绑定和事件触发器。

我认为这是一个设计问题而不是技术问题。