在ASP.NET MVC视图中使用代码后台是否被认为是一种不好的做法？今天我和同事们进行了一场辩论，想知道社区的想法。
显然，在使用类似Rails的另一个MVC时，这不是一个选项，这让我觉得它更多地被那些习惯于使用传统ASP.NET Web Forms应用程序的人所依赖。
使用Code-Behind与ASP.NET MVC视图
5
- jamesaharvey
1
2人们往往懒惰（即使是在学习方面）。每个开发者都应该遵循座右铭：“把懒惰鬼赶出你的身体”。从一开始就做对。避免将Web表单与MVC混合使用。 - Robert Koritnik
7个回答
11
我认为在ASP.NET MVC中使用code-behinds是一种不好的做法。MVC允许将表现逻辑（在视图中）与应用逻辑（在控制器中）分开。使用code-behinds会将表现逻辑和应用逻辑混合到code-behinds中，从而破坏MVC的一些好处。
- Johnny Oshika
2
6在我参与的多个中等规模的ASP.NET MVC项目中，我发现通过使用jQuery和控制器动作调用，我没有遇到过无法完成的任务 - 这意味着我并没有发现需要使用代码后台的必要性。请注意，该翻译保持了原文的含义并尽可能地通俗易懂，但并未添加解释或额外内容。 - CmdrTallen
2你希望将应用程序的逻辑放在模型中。控制器仅应用于链接视图和模型数据。 - Ryan Lanciaux
8
当然，《ASP.NET MVC In Action》的作者也不建议这样做，我也同意。这并非必要，那为什么要这样做呢？在早期的测试版中，确实包含了code-behind文件，但在RTM（或者是在其之前）时被移除了。
通常情况下，这只会鼓励你在视图中进行更多非视图工作，因为它会被忽略掉/被遗忘。
通常情况下，这只会鼓励你在视图中进行更多非视图工作，因为它会被忽略掉/被遗忘。
- Marc Gravell
6
我在第一个ASP.NET MVC项目（Preview 3！）中广泛使用了代码后台——主要用于将ViewData [“ foo”]转换为强类型数据对象，将视图数据收集到可枚举对象中以便进行循环等操作。
随着强类型视图的引入和（可怕命名的）Model-View-ViewModel模式的实用化使用，自从在最终版本发布之前从项目框架中删除它以来，我一直没有想念过代码后台。
我现在坚信，无论您在视图的代码后台中执行哪些处理，都应该更好地将处理结果建模为您的ViewModel，允许控制器执行实际处理，并使视图尽可能简单轻量。这将让您测试处理逻辑，使视图更易于修改，并创建 - 我认为 - 在转换数据以供显示和实际显示之间形成更优雅的分离。
- Dylan Beattie
5
是的，Code behind（即代码后台）长期以来一直是业务逻辑的秘密藏身之处，我们都知道这些内容不应该出现在View层。
从中移除Code behind是为了防止开发人员受到诱惑而做出不当行为。
- Johnno Nolan
3
我建议尽可能避免在MVC应用程序中使用codebehind。使用codebehind会抵消使用MVC框架所获得的一些价值，例如关注点分离等。您希望将数据访问、业务规则、类型转换等应用于Model中。如果您发现需要像Dylan提到的那样转换数据类型，则可以创建ViewModels。ViewModel基本上是您想要显示的实际Model中的数据，以您希望显示的格式。
- Ryan Lanciaux
2
最好在使用MVC时避免在代码后面放置任何内容。我很想知道关于哪个部分正在进行辩论，是否要将其放在代码后面？
如果您是Asp.Net MVC的新手，我真的建议您花些时间浏览Nerd Dinner示例。这里提供了一个免费的电子书和源代码http://nerddinner.codeplex.com/。
从头开始创建简单的演示是学习的好方法。完成此操作后，可能会让您了解代码中已有的代码可以放在哪里。
注意：如果您遵循电子书，请从codeplex中获取最新的site.css文件，否则虚拟地球地图将无法正确对齐。
希望对您有所帮助。 Ralph
如果您是Asp.Net MVC的新手，我真的建议您花些时间浏览Nerd Dinner示例。这里提供了一个免费的电子书和源代码http://nerddinner.codeplex.com/。
从头开始创建简单的演示是学习的好方法。完成此操作后，可能会让您了解代码中已有的代码可以放在哪里。
注意：如果您遵循电子书，请从codeplex中获取最新的site.css文件，否则虚拟地球地图将无法正确对齐。
希望对您有所帮助。 Ralph
- Ralph Willgoss
0
需要注意的是，“Code Behind”是Web Forms视图引擎的一个功能。它与ASP.NET MVC本身没有任何关系。
例如，在MVC3中，Razor视图引擎甚至不支持它。
我会这样回答你的问题：如果你无法在不重写控制器（甚至是模型）的情况下切换视图引擎，则没有正确使用MVC模式。
可能你在.aspx.cs文件中大部分的工作应该在模型（或视图模型）传递给视图之前完成。话虽如此，在我从ASP.NET Web Forms迁移到ASP.NET MVC的项目中，我保留了很多Code Behind。例如，我发现使用Repeater控件比在Web Forms中尝试使用“for”循环更清晰、更令人愉悦。毕竟，我只是对视图模型数据进行迭代。所以为什么不呢？关注点分离得到保留（实际上可能更好）。
我的意思是，为什么Web Forms的“最佳实践”突然成为Web Forms View的错误方式？以一个简单的例子来说，考虑一个Repeater，它为表格的每一行分配不同的CSS类。为什么我的控制器（甚至我的模型）要关心这个呢？试图在Web Forms中内联这种逻辑很快就会变成标记汤和完全的混乱。现在想象一些更复杂的东西。
我保留了Master页面，它在代码后台构建菜单。同样，所有数据都来自View Model。我不认为以这种方式使用GridView或其他控件会有问题。
我通常在Web Forms中禁用ViewState，并在“Init”中进行数据绑定。尽管如此，仍然会有一些小的ViewState无法摆脱。我在“Render”中放置了一些代码，将其移动到表单之后（默认情况下为之前）。当转移到MVC时，我有时会保留这段代码。因此，我确实使用了Code Behind的ASP.MVC站点。我只是小心，确保它是特定于视图的代码。
在新项目中，我通常发现大多数页面不需要Code Behind。值得庆幸的是，像Razor这样的视图引擎使得混合代码和标记变得更加容易编写、阅读和维护。
- Justin
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接