ASP.NET MVC 与 Web Forms

      今天早上在公交车上和少宇聊天，他最近在研究ASP.Net MVC，这是VS2008 .net3.5里新增加的一种架构模式，因为我现在做的项目还是2005，而且迁移起来比较麻烦，因此迟迟都没有彻底的用3.5做项目，但是一些新特性我还是了解了一些，Linq，MVC，原型方法（好象不叫这个名字）,DRL，今天又深入了研究了一下MVC，看了老赵的几篇文章和网上朋友对Web forms和mvc的争论，使我感觉仿佛又回到了想当年是用JAVA好还是.NET好，再往前是ASP好还是别的什么语言好，是VB好还是VC好的话题上了。

 

      我个人的认为是，微软花了十年功夫打造.NET，而它在应用中的表现也着实证明了，它是一个很强大的框架，以前我们一直用web forms这种处理模式来处理我们的应用程序，就象老赵说的，我们也可以做MVC模式的应用，有时当我需要做一些比较复杂的页面表格或是显示的时候，也会直接在ASPX直接写代码，如果有大量的类似的前台显示时我就干脆做一个类专门为一堆ASPX来提供显示，然后建很多ASPX，它的后置都使用这一个CS,然后我在页面上给他区分之间的不同.

 

      让我感触很深的是， 记得以前去一家公司，跟这家公司的技术主管聊天的时候，他做的是一个典型的互联网社区，他们要做的项目，第一要禁用ViewState第二要使用Repater第三要直接取Request和Response，页面回归到原始的ASP写法，第四要使用编译模式，以获得最在的执行性能。那是几年前的事儿了，其它他的要求跟现在MVC中应用的一样，如果当时有ASP。NET MVC的话，我想他就会告诉我他要用ASP。NET MVC来实现，所以用MVC的确很合适，但是当时并没有MVC怎么办呢，后来我们依然做到了，说实话在当时来说也不算太复杂的应用，也就是说，我个人认为MVC只是一个.NET的另一种处理方式，去掉了很多复杂的Web forms模型，使用了扁平化的管理，但是如果我经常需要处理的是业务逻辑经常变化，而且需求很简单的增删改查，而且动则几百个功能块，好象用forms模型就更加容易实现，而MVC仿佛就比较麻烦了估计光URL的管理就很麻烦。

 

     从技术角度来说，当一个请求进入到ASP.NET的ISAPI后交给HTTPProcess然后又会经常N个HTTPModule然后使用Page类的生命周期来管理页面,同时配合ViewState来进行Postback的处理,大大的提升了开发效率.另一方面来说,它的确是有性能上的折损.有时的确会怀念当时写ASP的时光,需要什么就回传什么,前台页面想怎么布就怎么布,但现在大多数时候都需要考虑控件的实现方式.于是我学习了ASP.NET控件与组件开发的红皮书(好家伙,那书可真厚).当我终于习惯了使用控件或在不得以的时候使用直接在页面中写入当年ASP里面叫做泥潭似的代码的时候,我发现,时代又变了.

 

      ASP.NET MVC可以说使用了另一个HTTPProcess来处理,我认为他仿照了JAVA或ROR的处理模型克隆了一套.NET版的实现,因为MVC嘛，基本上所有语言都是那样儿实现的，JAVA和ROR已经把它用的很强了,如果想用.NET来做MVC不如直接用JAVA或ROR做得了.

 

     我觉得一个优秀的.net程序员一定要看清物质的本质,不管是MVC还是forms其实只是process不同尔已,我还见过按约定编程的process,什么都不用写,建个数据库,一个应用就起来了,一切都按约定做好了.现在主流MVC和PAGE其实只是经过了不同的Process,而我有理由相信,froms的引擎要比MVC的引擎复杂的多的多,关键是看我们用哪些不用哪些，不用的我们可以扔掉，而且我觉得从古老的面向过程编程,到面向对象编程到面向组件编程这个发展趋势下,面向组件编程目前还是可重用性最高的.

 

     我坚信.net的程序员如果功底够扎实的话,完全可以自己处理各种的请求,扩展各种模式,就象我教育新入职的同事时一般会建议他看c#和.NET的知识,而不要沉迷到ASP.NET里的知识,因为以往的ASP.NET知识实际上是讲froms的,而若是一切换了处理模式,象现在的MVC模式,就会傻眼了,一切都要重新学起.说不定当他们刚学会MVC的时候,又出了什么另的模式的应用呢.呵呵.

 

就写到这儿吧，以上仅是我一家之词并不代表大众，由于本要技术浅薄如果表述不当之处请各位原谅