将代码隐藏与 ASP.NET MVC 视图一起使用答案

【问题标题】：Using Code-Behind with ASP.NET MVC Views将代码隐藏与 ASP.NET MVC 视图一起使用
【发布时间】：2014-08-23 18:51:01
【问题描述】：

将代码隐藏与 ASP.NET MVC 视图一起使用是否被认为是一种不好的做法？今天和我的同事就这个问题进行了一些辩论，我想知道社区的想法。

显然，当使用像 Rails 这样的其他 MVC 时，这不是一个选项，这让我认为它更多地被依赖于那些习惯于使用传统 ASP.NET Web 窗体应用程序的人。

【问题讨论】：

人们往往很懒惰（即使是在学习）。每个开发人员都应该遵循座右铭：“让懒惰的混蛋离开你的身体”。从一开始就做好。避免将 Web 表单与 mvc 混合使用。

标签： asp.net-mvc

【解决方案1】：

我会说将代码隐藏与 ASP.NET MVC 一起使用是一种不好的做法。 MVC 允许关注点分离，其中表示逻辑（在视图中）与应用程序逻辑（在控制器中）分离。使用代码隐藏将在代码隐藏中混合表示逻辑和应用程序逻辑，从而破坏 MVC 的一些好处。

【讨论】：

我没有发现任何我无法通过 jQuery 和 Controller Action 调用完成的事情——这意味着我还没有发现“需要”在几个中型 ASP.NET MVC 上的代码背后我参与的项目。
您希望模型中的应用程序逻辑。控制器只能用于连接视图和模型数据。

【解决方案2】：

ASP.NET MVC In Action 的作者当然反对它，我同意。没必要，为什么要这么做？在早期的 beta 版本中包含了一个代码隐藏文件，但在 RTM（或不久之前）被删除了。

通常，它只是鼓励您在视图中做更多的非视图工作，因为它是看不见/心不在焉的。

【讨论】：

【解决方案3】：

我在我的第一个 ASP.NET MVC（预览版 3！）项目中广泛使用了代码隐藏 - 主要用于将 ViewData["foo"] 转换为强类型数据对象，将视图数据收集到 IEnumerables 中，这样我就可以循环遍历它，诸如此类。

随着强类型视图的引入，以及（可怕地命名的）模型-视图-视图模型模式的实用使用，我没有错过任何代码隐藏，因为它在最终版本。

我现在强烈认为，无论您在视图的代码隐藏中执行什么处理，最好在 ViewModel 中对该处理的结果进行建模，让控制器执行实际的处理，并尽可能保持视图简单和轻量级。这将让您测试处理逻辑，使视图更易于修改，并创建 - 我认为 - 在转换数据以进行显示和实际显示之间更加优雅的分离。

【讨论】：

【解决方案4】：

是的，代码隐藏长期以来一直是业务逻辑的秘密藏身之处，众所周知，它不应该在视图级别。

已删除代码背后的代码以阻止顽皮的开发人员受到诱惑。

【讨论】：

【解决方案5】：

我建议不惜一切代价避免 MVC 应用程序中的代码隐藏。使用背后的代码否定了您通过使用 MVC 框架获得的一些价值，例如关注点分离等。您希望在模型中应用您的数据访问、业务规则、类型转换和类似的东西。如果你发现你需要像 Dylan 提到的那样转换你的数据类型，你可能想要制作 ViewModels。 ViewModel 基本上是您希望显示的实际模型中的数据，采用您希望显示的格式。

【讨论】：

【解决方案6】：

使用 MVC 时最好避免在代码中添加任何内容。
我很想知道正在讨论哪个部分，进入代码隐藏？

如果您是 Asp.Net MVC 的新手，我真的建议您花一些时间阅读 Nerd 晚餐示例。这里有免费的电子书和资源http://nerddinner.codeplex.com/。

从头开始创建简单的演示是一种很好的学习方式。
完成此操作后，它可能会阐明您在代码隐藏中的代码可以选择去哪里。

注意：如果您确实遵循电子书，请从 codeplex 获取最新的site.css 文件，否则虚拟地球地图将无法正确对齐。

HTH
拉尔夫

【讨论】：

【解决方案7】：

需要注意的是，“代码隐藏”是 Web 窗体视图引擎的一个功能。它确实与 ASP.NET MVC 本身无关。

例如，MVC3 中的Razor 视图引擎甚至不支持它。

我会这样回答你的问题：如果你不能在不重写你的控制器（甚至你的模型）的情况下切换视图引擎，那么你就没有正确使用 MVC 模式。

可能您在 .aspx.cs 文件中所做的大部分工作都应该在模型（或视图模型）传递到视图之前完成。也就是说，在我从 ASP.NET Web 窗体迁移到 ASP.NET MVC 的项目中，我留下了很多代码。例如，我发现使用 Repeater 控件比尝试在 Web 窗体中使用“for”循环更简洁、更令人愉悦。毕竟，我仍然只是在迭代 View Model 数据。那为什么不呢？保留了关注点的分离（实际上可能在更大程度上）。

我的意思是，为什么 Web 窗体的“最佳实践”突然变成了执行 Web 窗体视图的错误方法？举个简单的例子，考虑一个Repeater，它为表格的每一行分配一个不同的CSS 类。为什么我的控制器（甚至我的模型）应该关心？试图将这种逻辑内联在 Web 表单中很快就会变成标签汤和完整的意大利面条。现在想象一些更复杂的事情。

我已将母版页保留在后面的代码中构建菜单的位置。同样，所有数据都来自视图模型。我也不明白为什么以这种方式使用 GridView 或其他控件应该是一个问题。

我通常在 Web 窗体中禁用 ViewState，并在“初始化”中进行数据绑定。尽管如此，还是经常会有一个我无法摆脱的小型 ViewState。我在“渲染”中放置了一些代码，将其移动到表单之后（默认为之前）。在迁移到 MVC 时，我有时会留下这段代码。所以，我的 ASP.MVC 站点确实使用了 Code Behind。我只是小心它的代码是特定于视图的。

在新项目中，我通常发现在大多数页面上对 Code Behind 的需求较少。值得庆幸的是，像 Razor 这样的视图引擎已经让混合代码和内联标记在编写、阅读和维护方面变得不那么痛苦了。

【讨论】：