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