问题描述
有些人，喜欢webform控件简单好用，没错，不过复杂呢？看看fineui去，你做webform控件好还是js控件好？这问题够本质了吧。当然webform的控件以及用户控件还是有其不可替代性，无与伦比的封装性。不过js控件更是潮流，我更倾向于js。canvas里的东西你也打算用C#控制么？是吧。有的人，webform下终于会用js+ajax了，会用mvc模式了，不过asp.netmvc同样用jsajaxmvc，用同样的东西，闭源开源你选哪个？可扩展和写死的你选哪个？可替换和写死的你选哪个？这个问题不够容易么？当然了，我也没叫你老的项目一定要迁移，而是新的独立的项目的倾向性，所以别脑补说，啊，我公司一大堆。。。东西，怎么可能全换成mvc，呵呵，这样的人真不少,而且没不让你混合使用，即便是ajax，controller也比asmx，ashx好用不是么，即便是restful，webapi也比wcf等好用扩展性更好不是么。好了，闪人了，改密码去。
解决方案
解决方案二：
引用楼主gxrsprite的回复:
即便是ajax，controller也比asmx，ashx好用不是么
当然不是。controller脱离了view，连“命根”都阉割了，还叫controller都丢人。引用楼主gxrsprite的回复:
即便是restful，webapi也比wcf等好用扩展性更好不是么。
webapi封装这跟本不是asp.netmvc中的某一层中的任何模块，没有关系。
解决方案三：
该回复于2015-10-31 23:39:53被版主删除
解决方案四：
用了又怎样，又用又怎样
解决方案五：
当然是本身的GridView好了..不管是你说的UI还是easyUI,生成的东西比"控件"本身生成了更多了垃圾..导致效率更慢..当然肯定有很多人反驳我.自己生成一个GridView跟UI的grid之后F12自己看下就知道了..
解决方案六：
各种技术都是砖，哪里需要哪里搬。
解决方案七：
坚决抵制web控件，逻辑复杂，让人有很多想法，但去实现的时候问题一大堆。数据存储的地方太多，各种复杂。
解决方案八：
虽然我好几年没用webform了，但觉得这事不能一概而论，如果是企业内部应用项目，我觉得用webform开发更合适，不需要太在乎性能，开发速度快，而如果是类似于网站等普通的web项目，则最好用MVC，能够完全控制最终生成的html，性能也比webform有很大提升。
解决方案九：
具体问题具体分析，如果是内网的项目，我毫不犹豫的会用webform，开发快就可以了。
解决方案十：
引用5楼5653325的回复:
各种技术都是砖，哪里需要哪里搬。
同意这种说法
解决方案十一：
现在很多网站前台使用mvc，因为注重性能和响应速度，自定义程度高。后台大部分还是使用webform，因为后台只有公司内部人员使用，要求快速开发，方便后期修改和开发。
解决方案十二：
各种信息管理系统用WEBFORM的多，如果纯粹的网站用MVC的相对多一点，不过做网站用.NET的不多
解决方案十三：
业务最主要，关注这些技术优劣，没意义
解决方案十四：
其实不管是asp.netwebform、asp.netmvc、j2ee还是php、python、ruby的各种b/s项目。最终的还不都是html+css+javascript。考虑到底用什么主要还是看怎么样帮公司节约成本以及维护起来方便。
解决方案十五：
引用5楼5653325的回复:
各种技术都是砖，哪里需要哪里搬。
哈哈
解决方案：
引用1楼sp1234的回复:
Quote: 引用楼主gxrsprite的回复:
即便是ajax，controller也比asmx，ashx好用不是么当然不是。controller脱离了view，连“命根”都阉割了，还叫controller都丢人。引用楼主gxrsprite的回复:
即便是restful，webapi也比wcf等好用扩展性更好不是么。webapi封装这跟本不是asp.netmvc中的某一层中的任何模块，没有关系。
说asp.netmvc框架本身的时候，你又说道mvc架构去了，呵呵哈哈。
解决方案：
引用7楼webdiyer的回复:
虽然我好几年没用webform了，但觉得这事不能一概而论，如果是企业内部应用项目，我觉得用webform开发更合适，不需要太在乎性能，开发速度快，而如果是类似于网站等普通的web项目，则最好用MVC，能够完全控制最终生成的html，性能也比webform有很大提升。
webform有个引导作用就是让人去用服务端控件，你后台管理有套好用点的控件库还好点，但是你是引导别人用updatelpanel+ajaxtoolkit么？我在的公司就差点这条路走到黑了，推荐别人用webform的时候是不是得跟踪一下别人是不是走偏了？你是不是应该提供技术框架引导别人正确的使用？mvc引导人必须用jsajax，无论怎么推荐，拿来做什么都不会算错。
解决方案：
引用12楼fssssssss的回复:
业务最主要，关注这些技术优劣，没意义
开发人员不关心业务，只关心怎么实现方便舒服可维护，不会遇到诡异的问题和瓶颈。
解决方案：
该回复于2015-05-31 23:31:37被版主删除
解决方案：
MVC的性能并不比WebForm强，这是有实验数据的。MVC的长处在于它的可测试性和AOP特性。WebForm作适当优化的话，性能还是刚刚的。
解决方案：
解决方案：
asp.net的mvc和你们所说的一般的mvc一样吗
解决方案：
其实用mvc+ajax+js/JQ总感觉绕了一圈。。所以还是RESTFUL好用，视图和控制器绑定，直接展示。
解决方案：
web三大编程模型WebPage:::其实80%的网站是这个模式开发的。。简单快速，以前的asp,php，jsp都是这个模式。。缺点是一旦项目上规模，可能不太好管理WebForms：：这个事件驱动的模式，有几个优点，与桌面编程模型统一了，而这个模式是ide支持最方便的模式。。具体用不用webform，看你的ide支持程度了。。.net的就支持很好，而java的jsfide支持的就差多了。。所以java的webform模式不流行。。手写webform效率太低，除非是为了同时与桌面程序相统一。。和MVC：：这个在java中用的最多。。原因很简单，java的ide对webform支持不足。。而java又常常搞大项目，不太适合webpage模式，所以只能选择mvc了。。而.net的mvc就很少选择，因为ide对webform支持很好，开发速度与简单性webform毕竟比mvc好太多了。未来趋势：：webform：：web与桌面编程模型的统一是大势所趋，ide的支持会更加的好。事件驱动简单化了开发。。所以，webform必然会大放异彩mvc：：目前的ide技术对mvc支持困难，手写的比较多，效率慢，模式也比较复杂些，所以是要淘汰的一个技术了webpage：：属于过渡技术。。但是生命力要比mvc稍微强点。。一旦ide对webform的全面支持，就岌岌可危了。。不过，php这一类脚本目前ide支持有限，但是比mvc要好，所以应该会保留稍微长点的时间。。
解决方案：
我觉得对管理系统,内部系统而言,WebForm具有很大的优势,这类系统共同的特点就是大量表单处理,数据绑定,如果用MVC的话开发效率是较低的,用WebForm就很快.框架可以很好的支持WebForm，有专门的数据控件，大家可以看看源码里面的超市管理系统的例子。
解决方案：
脱离业务需求（实际业务之外，如目标运行环境）/开发效率（人员熟练程度，项目进度等）的基础去讨论什么技术好不好，过时不过时没什么太大意义。纯挑起口水仗。
解决方案：
引用23楼attilax的回复:
web三大编程模型WebPage:::其实80%的网站是这个模式开发的。。简单快速，以前的asp,php，jsp都是这个模式。。缺点是一旦项目上规模，可能不太好管理WebForms：：这个事件驱动的模式，有几个优点，与桌面编程模型统一了，而这个模式是ide支持最方便的模式。。具体用不用webform，看你的ide支持程度了。。.net的就支持很好，而java的jsfide支持的就差多了。。所以java的webform模式不流行。。手写webform效率太低，除非是为了同时与桌面程序相统一。。和MVC：：这个在java中用的最多。。原因很简单，java的ide对webform支持不足。。而java又常常搞大项目，不太适合webpage模式，所以只能选择mvc了。。而.net的mvc就很少选择，因为ide对webform支持很好，开发速度与简单性webform毕竟比mvc好太多了。未来趋势：：webform：：web与桌面编程模型的统一是大势所趋，ide的支持会更加的好。事件驱动简单化了开发。。所以，webform必然会大放异彩mvc：：目前的ide技术对mvc支持困难，手写的比较多，效率慢，模式也比较复杂些，所以是要淘汰的一个技术了webpage：：属于过渡技术。。但是生命力要比mvc稍微强点。。一旦ide对webform的全面支持，就岌岌可危了。。不过，php这一类脚本目前ide支持有限，但是比mvc要好，所以应该会保留稍微长点的时间。。
我不是这样看的webpage是根本~所以不存在被淘汰之说~现在前端框架越来越多和完善~不会在用webform这笨重的服务端控件了
解决方案：
引用26楼moonwrite的回复:
Quote: 引用23楼attilax的回复:
web三大编程模型WebPage:::其实80%的网站是这个模式开发的。。简单快速，以前的asp,php，jsp都是这个模式。。缺点是一旦项目上规模，可能不太好管理WebForms：：这个事件驱动的模式，有几个优点，与桌面编程模型统一了，而这个模式是ide支持最方便的模式。。具体用不用webform，看你的ide支持程度了。。.net的就支持很好，而java的jsfide支持的就差多了。。所以java的webform模式不流行。。手写webform效率太低，除非是为了同时与桌面程序相统一。。和MVC：：这个在java中用的最多。。原因很简单，java的ide对webform支持不足。。而java又常常搞大项目，不太适合webpage模式，所以只能选择mvc了。。而.net的mvc就很少选择，因为ide对webform支持很好，开发速度与简单性webform毕竟比mvc好太多了。未来趋势：：webform：：web与桌面编程模型的统一是大势所趋，ide的支持会更加的好。事件驱动简单化了开发。。所以，webform必然会大放异彩mvc：：目前的ide技术对mvc支持困难，手写的比较多，效率慢，模式也比较复杂些，所以是要淘汰的一个技术了webpage：：属于过渡技术。。但是生命力要比mvc稍微强点。。一旦ide对webform的全面支持，就岌岌可危了。。不过，php这一类脚本目前ide支持有限，但是比mvc要好，所以应该会保留稍微长点的时间。。我不是这样看的webpage是根本~所以不存在被淘汰之说~现在前端框架越来越多和完善~不会在用webform这笨重的服务端控件了
webpage就是以前的asp升级版吧。MVC应该是越来越流行才对吧，webform对于内网的管理确实是比较上手快，我做过一个教学管理管理系统，用的是linq，updatepanel+ajaxcontrolkit,(本想用jquery，但是在masterpage包裹中出了点问题，后来索性用MS自家的ajax方式)，但是大数据量的翻页好像很慢（listview+linq）
解决方案：
存在即合理，管它干嘛，还不是公司说用什么你就用什么
解决方案：
后台为毛要用webform？内部使用winform不更好？如果要移动设备使用，干脆开发App，比不上不下的webform强多了
解决方案：
各有各的好处吧，不能一概而论，要看具体业务逻辑和需求来选择。
解决方案：
本人一直在用