我在检查了这个网站一段时间后，我刚刚完成了一些MVC教程。它只是我，还是MVC View页面带回了经典ASP意大利面条代码的可怕闪回，所有跳入和跳出的HTML和ASP.NET都带有黄色分隔符，无法读取？什么事情发生在代码/设计分离的重要性？在教程点击View页面开发部分之前，我真的被新技术所推销。
或者我错过了什么？ （并且不要说你可以使用模板来帮助，因为它将意大利面条移动到另一个位置 - 将它扫到地毯下 - 它不能解决问题）
答案 0 :(得分：24)
见杰夫的帖子（http://www.codinghorror.com/blog/archives/001155.html）回应了你的问题，Rob Conery的回答（http://blog.wekeroad.com/blog/asp-net-mvc-avoiding-tag-soup/）
总之，ASP.NET MVC让开发人员可以选择在脚下拍摄自己，尽管它可以干净利落地完成。因此，它适合那些对Web开发感到满意并且风格简洁的开发人员，但是对于那些希望Widgetized行为的开发人员来说，不需要深入研究标记就不适合。
答案 1 :(得分：8)
如果您不喜欢默认的View引擎，可以使用另一个。
团队使用ASP.NET MVC所做的一件事是确保您可以使用任何类型的“视图引擎”。这为您自定义渲染引擎提供了很大的灵活性。
我们将来会调查一些更具声明性的视图引擎 - 尽管还没有特别规划。
答案 2 :(得分：8)
Finlay Microsoft正在通过ASP-Classic向ASP.NET步骤纠正他的错误。 70％的旧asp程序员使用PHP，因为ASP.NET很复杂。
他们坚持认为，使用ASP.NET药物和删除菜单可以解决所有问题。最后一切都在 form 标签内！我们正在构建大型“网络表单”而不是网站。只需查看任何ASP.NET站点的HTML即可。绝对可怕！
ASP.NET MVC是新的HOPE，用于更清晰，更有条理的HTML代码和强大的业务逻辑。
答案 3 :(得分：6)
MVC与通用ASP.NET一样，自动和手动传输之间的区别。如果您想确定哪个档位用于哪个目的，何时换档以及优化效率，请使用手册。如果您想要的东西可以正常使用但可能没有很好地优化，或者灵活，或者易于调试（您不需要经常这样做），请使用自动。
Classic ASP是一款只有二档的手动变速箱。
答案 4 :(得分：4)
不同之处在于，在MVC中，视图唯一要做的就是渲染显示。所有业务逻辑，I / O处理和与模型相关的代码都可以在控制器和模型类中找到。在视图中找到的代码量相对较小且紧凑 - 如果常用，您可以将其抽象为用户控件（部分视图）。
就个人而言，我喜欢我对视图的额外控制。我花在webforms上的大部分时间似乎花在尝试解决所做的默认假设（以及主页/子页面引入的名称修改）上，这使得很难在客户端执行任何操作。
编辑：我忘了提及创建HtmlHelper扩展方法的功能，这些方法可以让你将很多东西都移到后端。总而言之，在控制器，模型和扩展方法之间，它增加了许多代码，这些代码可以在MVC中轻松测试，无论是在经典ASP还是ASP.NET WebForms中。
答案 5 :(得分：3)
我认为ASP.NET视图引擎的问题在于你可以做什么没有限制，因为它只是嵌入在XHTML中的.NET语言。
相比之下，请查看Django template engine。在Django框架中，控制器和模型是使用完整的Python语言编写的，但视图模板引擎定义了一个受限语言，它只提供基本的编程结构（条件，循环等）。这种受限制的语言类似于Python，但实际上并不是Python，所以它不能像外部库那样调用任意代码。它只能访问传递给视图的模型数据。
任何嵌入通用语言的视图引擎都会遇到人们滥用它并在视图中执行不应该执行的操作的问题。因此，对于那些引擎，您确实需要尽职尽责地限制自己做其他事情而不是访问模型数据。
答案 6 :(得分：3)
在编写MVC一段时间之后，我将回到ASP.NET。
MVC确实是经典ASP或PHP向前迈出的一小步，但与ASP.NET相比，它是一个很大的进步。
许多可以通过ASP.NET中的几个步骤编程的东西需要在MVC中做更多的工作。 更难以满足最后期限。
这项技术有它的优点，但还不成熟。
也许在3.0版本中......
答案 7 :(得分：1)
这在PDC上提到过，他们确实提到它有点太“经典的asp”，就像所有＆lt;％=一样。但他们也提到他们将添加标准的ASP.Net标记和控件。
他们的整个方向是获得稳定的发布，然后更容易使用。
PDC视频：http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/PC21.wmv
答案 8 :(得分：1)
关于分离问题。在Classic ASP中，它是业务逻辑和表示逻辑的混合，为库提供了令人讨厌的内容。
此时语法类似，但目的不是。在视图中，您应该只进行表示逻辑。你仍然可以把业务逻辑放在那里，没有什么能阻止你（不幸的是）。这取决于开发人员，这仍然是我最关心的问题。
答案 9 :(得分：1)
查看StringTemplate视图引擎，看起来很干净。
答案 10 :(得分：1)
我总是对asp.net mvc的一些最大支持者所展示的对n层/层设计缺乏了解感到惊讶。 SOC在网络表格中一直是可以实现的。像MVP这样的UI模式在webforms中一直是可以实现的。这不是许多开发人员不知道如何设计的平台错误。
回到意大利面问题，我不得不同意。如果视图包含条件逻辑或大量不可测试的代码片段，则视图不应该是“哑”。
Personaly，我更喜欢MVP模式而不是MVC模式。
答案 11 :(得分：0)
因为MVC背后的人真的很喜欢ASP / JSP页面，并希望重新实现它。他们似乎讨厌：
他们似乎很喜欢：
MVC本质上是一种强制将代码与表示分离的方法。如果开发人员实际上足够关心，可以通过正常的Asp.Net轻松实现。无论如何，有可能推销整个“分离”系统，所以我真的没有看到这一点。
话虽如此，它有一些优点......但还不足以超过问题。 MVC第3版我肯定会很棒。
在有人标记我-1之前，看看我回答了多少个MVC问题。我知道我在说什么。
<强>更新 如果你认真对待你的分离，看着它，chaiguy1337就是一件好事。 String Template looks great因为它不允许您的前端有任何代码！在我看来，ASP.net MVC团队放弃了MVC。
答案 12 :(得分：0)
在传统的ASP中，您无法选择将业务逻辑移出UI层。在ASP.Net MVC中，“spaghetti”代码被隔离在UI层，View; 90％的逻辑将位于“M”和“C”层，这些是常规的非意大利语C＃类。
视图意味着“愚蠢”。从业务逻辑的角度来看，没有什么至关重要的。这意味着几乎是一次性的。
你可以在不对结构造成任何损害的情况下弄乱房间。如果您决定清理并重新涂漆，则无需致电建筑师。与View相同。
答案 13 :(得分：0)
记录：
我认为ASP MVC的真正的问题是控制器，使用（或模拟）某些模板方案（即使在ASP经典中）也是微不足道的（在大多数语言中），任何语言都可以做模型（有对象与否）但MVC强制你将控制器与视图和模型分开，使过程中的代码膨胀。
一个常见的网站依赖于完整形式的帖子/获取和AJAX，如果你同时使用它们，那么你将“C”从MVC变成一团糟。
最终，大多数程序员结束“作弊”，将ajax调用放在VIEW层中。