为什么会出现ASP.NET平台下的MVC框架?(转)

简介:

作者 Jonathan Allen译者 赵劼  http://www.infoq.com/cn/news/2007/12/MVC-vs-Web-Forms

Rick Strahl在他对ASP.NET平台下的Web Form和MVC框架的观察中首先谈到了Web Forms的强大之处。他提到,Web Forms已经被证明是一个非常稳定和成熟的平台。即使在性能要求非常高的情况下,它也不太会出现扩展方面的问题。同时,Rick还认为从Web Froms入门Web开发是一件非常容易的事情。 

微软设计了一个完整Web开发环境,使得构建Web应用有了新的体验,开发人员只需在一个可视化设计器中拖放控件、并且在表单中设置属性即可。与此同时,开发人员可以编写代码来响应事件,这使得对于程序逻辑的操作变得非常直观,就好像并非在开发一个Web应用一样。Web Forms模型提供了一个高度抽象的框架,使得入门变得非常容易。但是它也容易造成一些问题,因为它在很多方面将开发人员和低端的Web机制隔离开来。我稍候将回过来再谈一下这个次要的问题。

他在总结中谈到,这个框架有着非常强大的扩展能力,并且肯定了它对自定义控件这一产业所做出的贡献(可能ASP.NET控件厂商比其他平台下的总和还要多)。

对“高度抽象”进行了褒扬之后,Rick开始阐述它的缺点。

这既是一种幸运也是一个祸根。Web Forms让开发人员能够轻松地拖放控件,并且通过响应页面和控件的各种事件来快速开发Web应用。这一点很不错,但是首先这种高度的抽象使很多开发人员完全忽略了——甚至从没有了解过在这背后HTML是如何运作的。这往往会产生无法通过校验的HTML代码,或者是一些非常冗余,难以管理的HTML布局,这对于页面设计人员非常不友好。同时,如果没有合理控制ViewState的话,你很容易得到一个包含大量ViewState的页面,它的尺寸远远超过所需的内容,最终使得页面打开异常缓慢。

Web Forms框架的缺点之一,就是微软在这个抽象背后构建了一个非常复杂的引擎,它给页面的执行过程带来了许多的负面效应。如果你曾经构建过包含大量组件的复杂页面,就会发现某些时候要协调好数据绑定,页面生成等事件的顺序,并且在页面的生命周期中选择恰当的时间来设置不同的控件是一件非常困难的事情。你是否曾经在Init、Load或者PreRender事件中加载过数据?你是否在PostBack事件中进行过赋值?Web Forms需要服务器端的一个独立的表单中进行操作,因此你可能无法轻易地将它分解成小的逻辑单元。在一些复杂情况下,事件处理程序会变得非常庞大,你很难对它们的工作进行重构,最终你会得到许多难以维护的代码,并且几乎无法进行测试。

他继续详细讨论了ViewState,事件管理和PostBack机制的问题。对于这些内容还没有做到了如指掌的ASP.NET开发人员应该通过文章内容再努力学习一下。

有个问题可能会使非.NET平台的开发人员感到非常惊讶:我们很难在设计期间就确定一个控件的ID。由于文档中少有提及的命名容器链(Naming Container Chain)存在一定的缺陷,我们只有在运行时期才能知道“txtPassword”控件最终会获得一个形如“PublicSiteTemplate1_ctl00_txtPassword”的ID。而在使用其它技术开发的普通页面中,这应该是一个相对较短的ID。

含糊不清的控件ID以及ViewState对于如今的Web 2.0站点来说都是严重的问题。唯一不会受到ViewState带来的负面影响的框架是ASP.NET AJAX,但这还是一个不成熟的类库。(译者注:事实上,如果您使用了ASP.NET AJAX中的UpdatePanel控件,在客户端与服务器端交互的过程中依旧需要传递页面上所有的ViewState。另外,2006年最佳个人定制页面网站http://www.pageflakes.com/,也是基于当时的ASP.NET AJAX框架开发的,并且集成到.NET Framework 3.5中的ASP.NET AJAX又在各方面有了更进一步的改进,如果武断地称之为一个不成熟的类库未免有失偏颇)。

对我来说,Microsoft AJAX总体上无法成为我的首选客户端框架。它体积很大,并不十分模块化,而且对于客户端开发人员来说,一个本应该包含更多有用核心功能的客户端脚本框架,它提供的功能又非常有限。如果你将它和jQuery,Prototype,MooTools等包含强大功能的类库相比,感觉Microsoft AJAX严重缺乏一些在实际使用中有用的功能。同时,它包含的控件构建模型又显得死板而复杂,这些都无法成为选择Microsoft AJAX的理由,除非你想使用UpdatePanel或者AJAX Control Tookit中的服务器端控件。

接着Rick又谈到了Web Forms开发人员很容易将业务逻辑和表现层逻辑混合在一起。虽然使用Web Forms也可以将两者很好的分开,但是做到这点需要遵守相当数量的规则。

对于专业人员来说,Web Forms难以测试是一个更大的问题。Web Forms几乎无法做到自动测试,一部分原因是由于我们很难模拟Context、Response和Session对象,至于其他的原因还有例如我们很难处理它的事件驱动模型等。

MVC框架完全将这些缺点抛至一边,因为它舍弃了Page类和其他相关的负担。Rick是这样描述它的:

微软创建了另一种Http Handler来实现MVC框架,所以它完全与Page类无关,也避免了很多Web Forms框架所带来的复杂性。MVC框架的一个关键特性是提供了一种为特定任务生成内容而创建自定义视图(View)的能力。而控制器(Controller)负责使用各种模型来完成应用的核心任务,然后为视图提供生成页面内容所需的数据。例如,我们很容易想到为RSS或者其它XML输出的数据,亦或是类似登陆框或者出错页面来编写可复用的视图。然而,在默认情况下,生成视图的输出内容依旧使用了ASPX页面:ViewPage类。它基于Page类,但是并不会直接被HTTP Handler执行,而是被MVC引擎用作内容生成器,这比在完整的Web Forms框架中运行传统的ASPX页面要显得轻量了许多。

我们还是可以使用Web Forms框架中的部分控件和一些技巧,不过前提条件是它们不能依赖Post Back。和在页面中使用控件的传统开发方式不同的是,开发人员会发现他们需要使用大量的内联代码,就好像传统的ASP应用一样。

MVC模型在工作时是通过URL来选择应该执行哪个指定的控制器方法,并且任何的操作都会被引导至控制器中的特定方法。微软开发的引擎使用了类似Ruby(译者注:确切的说应该是Rails框架,Ruby只是一种开发语言)的机制来解析干净的URL(例如 http://localhost/Customers/Show/1),并且根据URL的格式将它们引导至特定的控制器,这种引导机制——就像MVC框架中的大部分东西一样——能够被很轻易地重新定义,这样你就能够使用不同的URL语法来将引导至特定的控制器。

同时,Rick发现一些有趣的东西,因为事物在过去十年中的发展形成了一个循环。

Web Forms模型曾经是.NET平台下Web开发最钟意的方式,在这个讨论中谈到这点显得多少有些有趣。事实上,我觉得有些讽刺的是,MVC框架在一定程度上回到了传统的ASP风格,那便是直接使用脚本来手动生成HTML的开发方式,而现在只是提供了一种更为严格的做法来将这种开发方式和代码逻辑区分开来。我还记得在早些时候,那些ASP.NET的疯狂追随者们是多么不屑使用内联的脚本标签,或者使用显式的URL而不是PostBack来进行开发的做法,而其中的一些人现在又毫不犹豫地张开双臂去迎接MVC框架,这难道不讽刺吗?

现在要确定MVC框架是否真正满足大多数Web开发人员的需要还为时过早。从现在所表现出来的结果上看,即使是开发简单的页面,MVC框架也需要大量的代码。我看过早期版本的MVC框架,但是并不清楚如何才能有效地编写一些更加复杂的页面,除非编写大量的选择语句来引导代码,我很难确定究竟页面上的哪一部份需要更新。以前我曾经开发过几个和MVC框架运作方式比较接近的Web开发框架,根据我的经验,它们总能很轻易的用于简单的页面开发,但是一旦页面上需要出现各种不同的、且相互独立的组件时,这些做法都逐渐出现问题了。使用基于无状态的控制器的做法来管理复杂度高的应用,要比目前Web Forms框架提供的功能要困难许多。至于这个框架会如何发展,以及最终会形成什么样的模式来处理复杂任务,我们都还需要拭目以待。如果关注一些Java或.NET平台下已经出现一段时间的MVC开发方式并加以比较,则可能会带来不小的帮助。

 最后,Rick是这样总结的:

到目前为止,我还没有打算将所有的希望押在一个新出现的,还没有被证明成功的框架,因为这好比连小孩和洗澡水一起倒了。Web Forms还是有许多优点,微软现在只是决定尝试一些新的事物,但这并不意味着我们必须完全转向它们。毕竟MVC框架出现的时间还不够长,现在还不能算作久经考验。虽然MVC框架很快就会吸引一批开发人员——但是对于其余像我们这样的人,微软还必须给出一个无比强大的框架,它至少需要能够在灵活性,扩展性和可用性等方面和Web Forms相媲美。有趣的事情还在前面,我也会兴致勃勃地关注它们……

查看英文原文:Why MVC for ASP.NET?


本文转自Kai的世界,道法自然博客园博客,原文链接:http://www.cnblogs.com/kaima/archive/2008/08/23/1274661.html,如需转载请自行联系原作者。

目录
相关文章
|
3月前
|
设计模式 开发框架 JavaScript
基于.NET8 + Vue/UniApp前后端分离的快速开发框架,开箱即用!
基于.NET8 + Vue/UniApp前后端分离的快速开发框架,开箱即用!
107 0
|
4月前
|
XML JSON API
ServiceStack:不仅仅是一个高性能Web API和微服务框架,更是一站式解决方案——深入解析其多协议支持及简便开发流程,带您体验前所未有的.NET开发效率革命
【10月更文挑战第9天】ServiceStack 是一个高性能的 Web API 和微服务框架,支持 JSON、XML、CSV 等多种数据格式。它简化了 .NET 应用的开发流程,提供了直观的 RESTful 服务构建方式。ServiceStack 支持高并发请求和复杂业务逻辑,安装简单,通过 NuGet 包管理器即可快速集成。示例代码展示了如何创建一个返回当前日期的简单服务,包括定义请求和响应 DTO、实现服务逻辑、配置路由和宿主。ServiceStack 还支持 WebSocket、SignalR 等实时通信协议,具备自动验证、自动过滤器等丰富功能,适合快速搭建高性能、可扩展的服务端应用。
269 3
|
1月前
|
C# Android开发 iOS开发
2025年全面的.NET跨平台应用框架推荐
2025年全面的.NET跨平台应用框架推荐
87 23
|
2月前
|
Linux API C#
基于 .NET 开发的多功能流媒体管理控制平台
基于 .NET 开发的多功能流媒体管理控制平台
54 9
|
2月前
|
监控 前端开发 API
一款基于 .NET MVC 框架开发、功能全面的MES系统
一款基于 .NET MVC 框架开发、功能全面的MES系统
|
2月前
|
消息中间件 开发框架 监控
NET任务调度框架Hangfire使用指南
Hangfire 是一个用于 .NET 应用程序的开源任务调度框架,支持长时间运行任务、定时任务等。通过简单的安装配置,即可将任务从主线程分离,提升应用性能。支持多种数据库,提供丰富的任务类型如立即执行、延迟执行和周期性任务,并有可视化管理界面 Hangfire Dashboard。还支持安全性配置及扩展插件,如 Hangfire.HttpJob,适合各种复杂场景下的任务调度需求。
101 1
NET任务调度框架Hangfire使用指南
|
3月前
|
开发框架 安全 .NET
在数字化时代,.NET 技术凭借跨平台兼容性、丰富的开发工具和框架、高效的性能及强大的安全稳定性,成为软件开发的重要支柱
在数字化时代,.NET 技术凭借跨平台兼容性、丰富的开发工具和框架、高效的性能及强大的安全稳定性,成为软件开发的重要支柱。它不仅加速了应用开发进程,提升了开发质量和可靠性,还促进了创新和业务发展,培养了专业人才和技术社区,为软件开发和数字化转型做出了重要贡献。
58 5
|
3月前
|
传感器 人工智能 供应链
.NET开发技术在数字化时代的创新作用,从高效的开发环境、强大的性能表现、丰富的库和框架资源等方面揭示了其关键优势。
本文深入探讨了.NET开发技术在数字化时代的创新作用,从高效的开发环境、强大的性能表现、丰富的库和框架资源等方面揭示了其关键优势。通过企业级应用、Web应用及移动应用的创新案例,展示了.NET在各领域的广泛应用和巨大潜力。展望未来,.NET将与新兴技术深度融合,拓展跨平台开发,推动云原生应用发展,持续创新。
59 4
|
3月前
|
开发框架 .NET C#
.NET 技术凭借高效开发环境、强大框架支持及跨平台特性,在软件开发中占据重要地位
.NET 技术凭借高效开发环境、强大框架支持及跨平台特性,在软件开发中占据重要地位。从企业应用到电子商务,再到移动开发,.NET 均展现出卓越性能,助力开发者提升效率与项目质量,推动行业持续发展。
58 4
|
3月前
|
机器学习/深度学习 人工智能 Cloud Native
在数字化时代,.NET 技术凭借其跨平台兼容性、丰富的类库和工具集以及卓越的性能与效率,成为软件开发的重要平台
在数字化时代,.NET 技术凭借其跨平台兼容性、丰富的类库和工具集以及卓越的性能与效率,成为软件开发的重要平台。本文深入解析 .NET 的核心优势,探讨其在企业级应用、Web 开发及移动应用等领域的应用案例,并展望未来在人工智能、云原生等方面的发展趋势。
56 3

热门文章

最新文章

相关实验场景

更多