除了设置ViewPage的常规参数外，ASP.NET MVC中视图文件背后的代码的目的是什么？

解决方案

没有目的只是不使用它，除了设置模型

ViewPage<Model>

有关更多信息，请参见此博客文章。

这是一个很好的问题。不使用特定的MVC模式，ASP.NET环境中不存在MVC。

查看= aspx

控制器= aspx.cs(代码隐藏)

型号= POCO(普通的旧C＃/ VB / .NET对象)

我想知道为什么MVC框架的新增功能会有所帮助。几年前(2001年)，我与Java nd MVC和Java Struts进行了大量合作，发现MVC中的概念可以解决当时的Internet应用程序组织和开发问题，但是后来发现背后的代码简化了控制器的概念，更快地发展并与他人沟通。我确信其他人不同意我的看法，并且我愿意接受其他想法。我认为MVC的最大价值在于Internet开发的前端控制器模式，这是Internet应用程序的单一输入源。但是，另一方面，使用当前的ASP.NET技术可以很容易地实现该模式。我听到其他人说单元测试是推理。我可以理解，在2001年，我们在MVC框架中使用了JUnit。但是我一直不相信它可以简化使用MVC框架的测试。

谢谢阅读！

在此Blogpost上，有一个删除后面代码的有效示例。
我唯一遇到的问题是它无法在类上设置名称空间。

后面的代码提供了一些强类型输入以及我们在视图中获得的智能支持。如果我们不关心这两个功能中的任何一个，则可以将其删除。

例如，我通常使用NVelocity ViewEngine，因为它很干净而且很简单。

最终，我们问自己一个问题是：

此代码是A)处理，存储，检索，对数据执行操作或者分析数据，还是B)帮助显示数据？

如果答案是A，则它属于控制器。如果答案是B，则它属于视图。

如果为B，则最终成为样式问题。如果我们有一些相当长的条件操作试图找出是否向用户显示内容，那么我们可以将这些条件操作隐藏在属性后面的代码中。否则，似乎大多数人都使用<％％>和<％=％>标签将代码内联到前端。

最初，我将所有显示逻辑放在<％％>标记内。但是最近，我开始在代码中添加任何混乱的内容(例如冗长的条件代码)，以保持XHML的整洁。这里的窍门是纪律，它很容易在后面的代码中开始编写业务逻辑，而这正是我们在MVC中不应该做的事情。

如果我们试图从传统的ASP.NET迁移到ASP.NET MVC，则可能会在不了解实践之前避免使用代码落后(尽管这样做仍然不会阻止我们将业务逻辑放入<％％中>。

这是我自己的帖子中列出为什么可以使用隐藏代码的原因的清单。我敢肯定还有更多。

• 数据绑定旧式ASP.NET控件-如果没有替代方法或者需要临时解决方案。
• 查看需要递归以创建某种嵌套或者分层HTML的逻辑。
• 查看使用临时变量的逻辑。我拒绝在标签汤中定义局部变量！我至少希望它们作为视图类的属性。
• 仅特定于一个视图或者模型且不属于HtmlHelper的逻辑。附带说明一下，我认为HtmlHelper不应了解任何"模型"类。如果知道模型中定义的类(例如IEnumerable，则很好)，但我不认为例如我们应该拥有一个带有ProductModel的HtmlHelper。当我们键入Html + dot时，HtmlHelper方法最终将在所有视图中可见我真的想尽可能地减少此列表。
• 如果我想编写使用HtmlGenericControl和该命名空间中的其他类的代码以面向对象的方式生成HTML的代码(或者我已有要移植的代码)怎么办。
• 如果我打算将来使用其他视图引擎，该怎么办。我可能要保留标签汤之外的一些逻辑，以使以后更容易重用。
• 如果我希望能够重命名Model类并使其自动重构视图而不必转到view.aspx并更改类名，该怎么办。
• 如果我与不信任HTML设计师协调，不搞乱"标签汤"，并且想在.aspx.cs文件中编写除基本循环之外的所有内容，该怎么办？
• 如果要基于视图的默认排序选项对数据进行排序。如果我们有多个只能从视图访问的排序选项，我真的不认为控制器应该为我们排序数据。
• 实际上，我们实际上想在实际看起来像.cs而不是HTML的代码中调试视图逻辑。
• 我们想编写稍后可能会分解并在其他地方重用的代码-我们尚不确定。
• 我们想对可能成为新的HtmlHelper的原型进行原型制作，但尚未决定其通用性是否足以保证创建HtmlHelper。 (与上一点基本相同)
• 我们想创建一个帮助器方法来呈现局部视图，但是需要通过从主页视图中抽出数据并为基于当前循环迭代的局部控件创建模型来为其创建模型。
• 我们认为在单个函数中编写复杂的逻辑是一种过时且不可维护的实践。
• 我们是在RC1之前完成的，没有遇到任何问题！

是的！有些视图根本不需要代码隐藏。

是的！除了.cs文件之外，它还很烂地创建了一个愚蠢的.designer文件。

是的！将那些小号+放在每个视图旁边有点烦人。

但是，不将数据访问逻辑放在后面的代码中并不难。

他们肯定不是邪恶的。