本文主要是介绍WebForm VS MVC，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
http://www.cnblogs.com/JeffreyZhao/archive/2007/12/22/Experience-for-Asp-dot-net-and-WebForms-2.html
文章摘录:
1. “不过web中非要弄个严格的m-v-c的意义大么”
Web中弄MVC(不论是否严格)，对我们来说，开发上选择的权衡筹码要远大于使用。
这也是为什么老赵在下面提到的用WebForm去完成种种“MVC”的效果，基本上都没有问题。
并且说彻底一点，MVC目前也就是System.Web.Mvc下面的一个命名空间内的内容（且不论MVCToolkit,到时候应该会集成到System.Web或者System.Web.Mvc），所以我们完全有理自己写一个类，取代Web.Mvc。从这点上来说，WebForm转型为“MVC”的“效果”似乎很简单。
但是WebForm和MVC是同功能不同框架结构的两种架构（或者对我们来说是不同的“开发、使用模式”和“开发、使用感受”）毕竟M-V-C的实现远远不是.aspx和.cs分离可以做到的，即使当初MS推出ASP.NET的时候，如何强调codebehind的优势，但是它在架构上回避不了一个问题（即使你可以不使用，但可能会给你带来不必要的绕弯）：如果全部codebehind的话，.cs势必需要担负起同时处理事务逻辑和视图各方面属性的任务。一个是对逻辑的控制，另一个是对视图（服务器控件）的控制。
这在所有畏“企业级应用”的开发过程中，往往会引发一些麻烦。至少我理想的比较复杂的系统（是视图和逻辑都很复杂，且不论是不是“企业级应用”），应当在美工和处理逻辑（不管是不是一个人完成）尽可能划清界限，第一有利于对逻辑本身的控制（程序员不用去老想着哪个控件要如何，或者这里是别人的范围我不能改），第二这给日后的维护提供了许多的便利，可以做到有的放矢，并且各板块的修改几乎不会相互影响（这点目前的MVC CTP似乎还没有完全做到）。
这就比如我们为什么常常要小心选择使用const和readonly去定义一个“常量，const更注重持久的比较稳定的值，一旦被编译，全局统一，而readonly在它所在的类被重新编译后，调用它的其他类只是引用地址，并不用重新编译，这种协调的模式就和C-V（当然也有部分M）从原先的codebehind中分离出来的协调方式，就有点像美工和逻辑之间的协调，大家围绕一个标准，进程上又互不影响。
2. WebForm VS MVC
WebForm的问题我刚上手几个月就感触很深了（可能和我的开发经历有关），对于有些问题，都是“隐藏”的，就像我说的判断一辆车是否超载不时要看他是否发生车祸。很多问题，除了直观的感受之外，可以按照他的逻辑去判断（WebForm/MVC在小团队测试下，直观上是难分高下的，而等到应用中发现效率问题又为时过晚，就像我当时发现WebForm一些问题时候的感觉。当然VS提供了负载测试功能，还是很不错的）。
现在说你的上面一句话“WebForms实现MVC也并不是指cs和aspx的分离”，我这个不是真对你说的，是当初ASP.NET给人的一种曲解（即便不是曲解为完整的MVC）。
你说WebForm做到那些(MVC)效果,不管是理论上还是实际上都是可行的：我们System.Web.MVC开发过程考虑，完全可以在WebForm的基础上，建一个类库，把MVC效果做出来，测试完成后，然后整合到System.Web下面（当然只是一种可行方案。特别像URL重写方面，WebForm已经比较成熟了）。这大概是你说的“不难”。
所以MVC和WebForm本质的区别并不在技术支持的本身，他们是同根的。最大的区别在于结构（对于我们来说更重要的是开发时的结构，虽然使用上MVC也有其他的优势），可以说结构上，决定了MVC和WebForm的区别。我们甚至可以看作MVC(CTP)是WebForm调整结构之后的产物（按照我上面的MVC开发假设）。所以我们似乎老是没有对在一个点上说，感觉分歧很大。
我是这么理解你的想法的，不知道对不对：WebForm可以完成MVC的一些效果，但是在完成的过程中，其实你已经用到了MVC的一些思想，既然如此，那么把WebForm改造成MVC又何难，然而，一旦把WebForm改成(趋于)MVC效果，为何就不直接使用MVC呢？
你举了一个例子，10个礼物，你拿4个，那么另外6个去哪了？如果使用MVC，那么可能是这样的情况：人家只送了你需要的4个，并且可以省去你选择的成本。（当然这里似乎把MVC说的太简单了）
补充以下，关于.aspx和.cs分离，对于ASP模式来说是一种飞跃，但是还是解决不了逻辑和视图的关系（我们但就考虑大家都使用codehehid的情况，虽然都在aspx页面编辑也行，但那就没有讨论价值了，并且趋向MVC转型的第一步了）。
我举一个很小例子，美工需要一个button在一个condtition下面不可见，这时候，你需要在.cs里面display=false，然后必须编译，等下一次，逻辑需要修改的时候，除了必须把View一起编译之外，程序员一边开发逻辑，还要一边照顾到那个button的状态，这个在效率上很难以保证，尤其是比较复杂的系统。我是说万一，他们沟通出问题或者由于操作失误，把这个button弄错了，这算不算一种低效？当然比较小的系统这样的问题比较容易避免，但也不能排除他的干扰。
开发方面，MVC注重的就是明确的分工和比较明确的流程。
我这里不是说这些WebForm的codebehind做不到，只是MVC在这方面，提供了比WebForm更好的解决方案。当然这是需要成本的，比如MVC前期的开发比WebForm要“繁琐”许多，文件也会增多许多（.aspx/.aspx.cs我们都看作一个文件）
3. WebForm中MVC理念
为什么你总是认为WebForms里面用到了MVC，就还不如用MVC呢？我用了MVC的思想，为什么就非要用到MVC框架，而抛弃WebForms的优势呢？这和认为“抛弃了ViewState和PostBack用WebForms就没有意义了”有什么区别呢？WebForms里的大量优势还是在的阿。MVC是理念，是逻辑上职责上的分离，和MVC框架与否，WebForms与否都没有任何关系。你这样也会误导初学者，好像MVC和MVC框架是同样的东西，而且已经有人分不清了……
现在的状况是，通过有用的4个礼物的组合，我能得到另外一个人送给的3件礼物中的2个。
还有你说的那个小例子（button在一个condition下不可见）不会有问题的，你现在所说的WebForms的缺点都是基于“误用”的基础上，但这个并非是WebForms的问题啊。而且正如你说，MVC前期的开发比WebForm要“繁琐”许多，我现在正是保留WebForms的优势而融入MVC理念阿，你说有没有意义？
4. MVC之(ViewState和PostBack)
我觉得你对MVC的理解似乎也有点误区，MVC完全可以完成WebForm的几乎所有同样的功能和方法（即便是ViewState和PostBack，MVC也能用），只要包含在form/server中就可以。
我并不是说WebForm实现一些MVC的效果就一定要完全使用MVC，毕竟MVC的开发成本可能不会比WebForm低（目前来看，很长一段时间都会这样）。我的意思是说，如果你把WebForm去实现一些MVC的功能，而去回避ViewState和PostBack，那就是我看中MVC的原因，因为MVC天生就解决了这个问题。这样我们就说到一点上来了
5. WebForm更适合做Web开发
呵呵，不多说了，总之就是，我说的在WebForm里实现的MVC不是MVC框架能够（轻松）替代的（除非以后微软将两者结合在一起）。WebForms是一个灵活的，比MVC框架要庞大许多的架构，自然能实现MVC的理念（注意不是MVC框架）。MVC框架很难做到WebForms的组件模型，它的优势更在于在某些情况下更适合Web开发（的概念或工作方式），但这并不能说明WebForms哪里不好，不适应Web开发。
6. (使用环境和开发对象)影响开发方式
我也从来没有说WebForms不适应Web开发。但是“哪里不好”，在一些情况下确实是他的弊端，这个是事实。即使你去回避了，那也是MVC本来就要求的，那么一个是方法，一个是整套解决方案，他们就有点殊途同归了。
适不适应Web开发也不是光一个结构或者理念可以决定的，还必须考虑到他的使用环境和开发对象。甚至我敢说有些条件下，html静态页面编写已经足以。
7. MVC的出现并不是为了解决技术问题，而是实际开发和操作问题
我还是那个观点，其实就Web开发本身，并没有那么多不同，所谓“企业级应用”和MVC等等，都是在实际开发实践中被强化分离出来的，对于实现基础的本身，在ASP.NET框架内并没有太大差异，差异在于他们处理逻辑的流程和板块的分工方式.MVC的出现并不是为了解决技术问题，而是实际开发和操作问题，它们之间是相通的。
MVC实现ViewState+PostBack（换句话说是实现WebForm中的一些“特性”功能）只需要你把Controller抛在一边，继续在.aspx.cs中开发（codebehind），把所有的服务器控件装入form/server(顺便提一点，MVC在一个网页内允许多个form，这点有点像ASP和普通的网页，所以对于表单提交的效率还是比较高的)，你就可以和WebForm上面一样使用ViewState+PostBack，但是MVC思想本身是不提倡这么做的（不然就没有分M-V-C的必要了），所以似乎在设计MVC(CTP)框架的时候，把这方面回避了一下，但是还是可以用（当作一个bug处理一下就行）：
8. 保留WebForms自身的优点
还有就是ASP.NET，MVC框架和WebForms三者是完全不同的概念。而MVC的执行引擎和WebForms是不同的，所以不能说他们在ASP.NET框架内并没有太大差异。MVC用aspx作为模版，其实也是一种“模拟”或者“复用”——已经不是WebForms了，虽然“模拟”能够带来一定的WebForms特点。
这就好像WebForm是无法做到MVC框架的工作方式的，但是可以模拟，可以体现MVC模式（不是框架）的设计。我在WebForms里实现MVC也不会仅仅去迎合MVC框架的做法，而是要解决开发中比如程序员和美工的配合等方面遇到的问题，当然还要保留WebForms自身的优点。
9. WebForm可以使用System.Web.Mvc的，MVC大部分都能使用
是你没有理解我的意思吧？我是说你想要实现的功能上，他们都是共享很多的功能的，这点我之前已经有过说明了，目前的MVC(CTP)的功能都被定义到了System.Web.Mvc和一些Helper中进行了扩展，难道这就说MVC只能使用System.Web.Mvc命名空间内的的东西吗？不是的，WebForm可以使用的，MVC大部分都能使用。
至于ASP.NET，MVC框架和WebForms三者的关系，我只是想强调，我们现在讨论的MVC或WebForms都是在ASP.NET技术范围内，不然就扯开去了。
10. webform与MVC并存
对于做BI的应用系统来说,webform还是可以让我吃尽甜头的
我想关键还是看行业应用吧,真正的企业级业务系统恐怕真的很难容忍webform,就目前的情况来看.
另外,asp.net的版本也已经过三了,是否会和当年asp一样的套路呢,MVC的出现是否说明了什么?
难道以后所谓的webform与MVC并存难道就是现在微软所宣称的asp.net与asp并存吗?关键还是看看待问题的角度了,从商业角度这么说没什么问题,但是从技术角度从技术人员群体来说恐怕就很难达成一致了.
11. MVC至少以“指令性”的URL替代了我们PostBack回去的ItemCommandName
MVC至少以“指令性”的URL替代了我们PostBack回去的ItemCommandName，至于数据，MVC是不直接处理页面数据的（这也是MVC不是用ViewState的原因），在Controller里面直接处理，效率上来说，反正每次都是要读数据库，所以剩下来的时间就是数据传输了。
因为我十分……ViewState，所以通常我还是回去避免，比如专门传入一个Action=bl&id=xx到某个页面，负责处理，但这样其实维护很麻烦，而MVC其实就已经（顺带）解决了这个问题
12. if{}else{} vs try{}catch{}
如果if{}else{}判断比较繁琐的话，值不值得用try{}catch{}来（if里面可以报错）？很久前就想找人讨论一下，今天突然又碰到了才想起来
这种情况下，最好不要用try/catch，首先是异常所带来的性能问题；其次，我感觉异常通常用于报告API的用户输入值的无效；另外，try会隐藏很多问题，异常可能是数据库返回null引起的，也有可能不是。
这篇关于WebForm VS MVC的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
