除了设置ViewPage的泛型参数之外,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文件很糟糕.
是! 在每个视图旁边获取那些小+符号是很烦人的.
但是 - 不要将数据访问逻辑放在代码隐藏中并不难.
他们肯定不是邪恶的.
最后,你问自己的问题是:
此代码A)处理,存储,检索,执行操作或分析数据,或B)帮助显示数据?
如果答案是A,则它属于您的控制器.如果答案是B,那么它属于视图.
如果B,它最终成为一种风格问题.如果你有一些相当长的条件操作试图弄清楚你是否向用户显示了某些东西,那么你可能会隐藏属性中后面代码中的那些条件操作.否则,似乎大多数人使用<%%>和<%=%>标记将代码内联到前端.
最初,我将所有显示逻辑放在<%%>标记内.但是最近我在我的代码中添加了任何杂乱的东西(例如冗长的条件)以保持我的XHML清洁.这里的诀窍是纪律 - 在后面的代码中开始编写业务逻辑太诱人了,这正是你不应该在MVC中做的事情.
如果您正在尝试从传统的ASP.NET迁移到ASP.NET MVC,那么您可能会避免使用代码,直到您对这些实践有所了解(尽管它仍然不能阻止您将业务逻辑放在<%%中) >.