我已经听到很多人说过这么一句话:"微软的WEB开发构架终于开始走向成熟了!",这句话的言外之意就是微软的WEB开发构架一直以来都是不成熟的!
对于那些拥护Webform postback和Viewstate/Controlstate的开发者我只能说抱歉了,因为我的的确确赞同这个说法!
我的确讨厌所谓的PostBack和Viewstate/Controlstate,它们总是把最后生成的HTML搞得混乱不堪；元素的ID也是 Javascript编写人员不可预料的(虽然这个尚可以解决,但是解决方案怎么看都不对劲)；CSS中也无法针对某个ID的元素进行控制！元素的ID通过<%=%>传给Javascript或Css的方式不美观而且有很多限制（如我们要在外部的JS 文件中得到ID），这也给调试带来了不便.
另外就是讨厌的Viewstate/Controlstate有时候太多了，加大了网络带宽也使得HTML混乱不堪，虽然它的确解决了服务器端缓存太耗资源的问题，而且也可以禁止ViewState。但是仍然有很多开发人员对“客户端/服务器端动态创建的元素/控件与ViewState”等问题很讨厌! 我就觉得自己写一个保持状态的轻量级解决方案要比Viewstate好.
用ASP.NET开发的网页的HTML是很不可读的,空格和缩进是不能事先预料的,元素的ID也是很难预料的.这些都很讨厌!
.NET 3.5中有了ListView 使得我们对HTML的控制更加自由了一些,我特别喜欢这个控件.
在ASP.NET MVC中,以前的postback机制自然是不可用了(当然我们可以编写一个自定义的状态维持机制), 正如Scott Gu所说:
It does not, however, use the existing post-back model for interactions back to the server. Instead, you'll route all end-user interactions to a Controller class instead - which helps ensure clean separation of concerns and testability (it also means no viewstate or page lifecycle with MVC based views).
很显然,微软已经认识到了以前的ASP.NET的落后,为了Ioc/MVC,可插拔性和可测试性,微软已经抛弃了POSTBACK! 软件开发的先进思想就是生产力的发展方向,不跟上最终就要被淘汰.
从Scott Gu的实例中可以看出,显然微软也建议使用像传统ASP一样的语法来精确地控制HTML或者使用Listview,以得到Javascript和CSS友好的HTML.要得到Javascript和CSS友好的HTML,精确地控制HTML得语法是不能丢的,可以强调代码后置和控件HTML封装,但是这些都应该是在分层设计上的事,不应该在形式上强调. 这点JSP一直做得较好.
微软是一家聪明的公司,一直以来不都是在落后几年之后迎头赶上吗?
有了MVC,一个较开放的MVC构架,微软的WEB开发平台势必也会趋大势与各开源ORM,UnitTest框架和工具更加紧密地结合, 与Java的WEB开发平台一样呈现百花齐放,百家争鸣的繁荣景象, 一个优秀的开源.NET IDE-- SharpDevelper的出现也预示着这一点. 未来微软的开发平台将更加开放,将与开源产品前所未有地结合.这无疑是一个好的趋势,让我们拭目以待吧!