一起讨论（asp.net项目实际开发中是否应用控件）

Question

开发项目有一点时间了，好像是为了速度的原因，asp.net的控件很少用，甚至可以说完全不用，有点像JAVA,界面数据全是拼凑<%=%>,asp.net的开发速度完全没有发挥出来。这样有必要么。

Answer 1

黑猫白猫，抓到老鼠的就是好猫。
你一直用<%=%>，只能说明<%=%> 已经能够满足你目前的开发要求了。

Answer 2

好像<%=%>能解决所有的问题。

Answer 3

但是那asp.net的优势好像没有了直接用java或者asp就行了。

Answer 4

大量采用服务器控件会有效率的问题。一般都尽量少用。
一般的开发都会使用Repeater这样的列表控件来实现数据列表，其他的业务处理都是用HTML控件实现，前台的验证都利用JS实现，很少使用到别的服务器控件的。由于程序员的水平不起，利用服务器控件和HTML控件互相配合开发的时候，很多程序员会混乱，不清楚什么样的控件怎么处理，各种验证应该是客户端还是服务器端实现。而且好多状态都被服务器控件管理，不是很好控制。我们以前开发的时候经常遇到这个问题，最后基本上都抛弃了服务器控件。实际上服务器控件也没多少用处。就算用了也没简单多少。反倒是生成了一堆垃圾代码。

Answer 5

实际上服务器控件也没多少用处。就算用了也没简单多少。反倒是生成了一堆垃圾代码。真的是这样么好像百分之八十的人选择asp.net就是因为控件了，照上面这样说直接用Java好了。

Answer 6

控件即使表格显示数据，用字符串在页面显示数据，效率不高
服务器控还是要使用，还可使用html控件

Answer 7

有些东西Repeater是实现不了的，必须用gridview或datalist或listview实现，比如双击当前行获取当前行数据
把所有数据selelct到控件再分页显示，即使用比repeater更轻量级的控件也会浪费大量资源。有些人以为会设置控件就会NET了，

Answer 8

在后台拼table显示数据，这是非常垃圾的做法

Answer 9

如果水平都差不多，用不用控件都可以商量着来。
不过现在很多开发组的人员结构不同，如果允许使用控件，大部分人都是简单设置而已了。至少我以前的项目组就是这样。最后的结果就是效率低下。维护起来很麻烦。一会儿前台控制，一会儿后台验证的。所以除非管理比较严格，而且有良好的代码review的组。否则用上控件可能更麻烦。

Answer 10

我现在更加的费解，前台拼接Table不好，控件用多了不好，我们还能干什么？

Answer 11

asp.net实际开发过程中我从来没有用过Datalist.GridView.我甚至都不知道怎么拖拽了，当前项目开发中前台页面甚至连button都没有用过服务器控件，这有必要么。

Answer 12

我感觉控件是asp.net 的一个不小的优势，如果放弃这个，好像有点可惜，我现在就想知道别的公司对于控件的态度，是没有限制呢，还是有范围，还是一定要用。

Answer 13

不是很同意您的观点
一般讨论的使不使用服务器控件我想大部分指的是数据显示控件
repeater datalist gridview 三个中只有repeater生成的html是干净的 
微软给datalist gridview 提供强大功能的同时也让生成的html变得很恶心listview很强大 而且生成代码也很干净 如果是使用的net3.5 是个很不错的选择您说的“把所有数据selelct到控件再分页显示” ，不知道实际项目中这样的需求是不是很多，至少我没有碰到过

Answer 14

javascript和ajax和html控件吧,少用服务器控件

Answer 15

我现在只用repeater别的都不用。 

Answer 16

把所有数据selelct到控件再分页显示，这个现在很少用的，效率极其底下。第二个，每个项目都有自己的特殊的操作，自己写控件比较好。

Answer 17

给普通访问者浏览的页面上不使用控件，因为页面的html、css等是设计人员的工作，现成的html，我不会再“翻译”成控件
给网站内部运营人员、编辑用的后台管理页面，直接上控件，设置设置属性、注意一下翻页什么的开销就差不多了

Answer 18

上帝的归上帝，恺撒的归恺撒
B/S里，那些事情给B，那些事情给S
为什么是B/S，而不是BS或者B+S呢？
就是因为这个/就是一条线，把这条线画清楚了，其它的问题就好解决多了

Answer 19

其实开发并不是程序员一个人的问题，HTML控件对于美工来说更具有亲和力。他们也能更好的融入开发工作中去。
大部分服务器控件的开发代码，和最后生成的实际代码，差别很大，对于这部分不是很了解的美工干起活来很费劲。
而且也别指望程序员可以协助美工来完成工作。他们能把自己的业务逻辑弄明白就不错了。团队合作中要考虑方方面面，最好的不一定是最合适的。选择一个适合自己团队的开发模式才是最重要的。

Answer 20

哪个方便就用哪个了，不单考虑开发效率，还要考虑将来的维护，后台全拼html很难维护的。

Answer 21

你们的美工，是在程序员开发好后，生成了ASPX文件，才进行样式调整？吹的吧，那岂不是每次更改都要重新改页面？

Answer 22

推荐使用控件，特别是对于web应用程序，如果都用table，stringbuilder那厉害了，asp也可以这样，java也可以这样，php，python估计都可以，那厉害了，都可以号称会了
一个平台，如果不把他的优势发挥出来，那选择这个平台的意义在哪呢？当然，用控件也一样分水平。别说我只会用控件，我用.NET做可视化工作流程设计的，但是有些时候确实适合用控件。

Answer 23

不清楚你们的开发模式到底是怎么样的，难道美工不需要接触Aspx页面？仅仅设计HTML页面给程序使用吗？
样式出现问题，或者框架错位的情况，到底由谁来解决，程序员还是美工呢？
如果都是服务器控件组成的页面，设计页面和最后生成的效果页面基本都是不一样的，你让美工如何进行修改呢？还是说你们的设计已经进化到完全的分离美工与程序了？如果真的是这么强的队伍，估计就没有讨论这个问题的必要了。

Answer 24

微软要看到这帖子
那个伤心啊费了那么大的心力，弄个控件来提升广大ASP.NET开发人员的开发效率，最后大家都不用。我到这觉得这是ASP.NET不同于JAVA,的一大优势，对开发效率方面提升很多，至于性能方面（微软肯定也会尽可能的提升控件的效率的），由于摩尔定律的原因，基本上是没问题的，效率不会相差多少，关键还要看你会不会用。当然 最终要看你项目组老大了，他决定用啥就是啥

Answer 25

我晕，美工做好HTML页面给开发人员就可以了，开发人员把页面加入到自己的程序页面中，进行简单的样式调整，你说的那些（样式现实有错位）有可能发生（但是绝不普遍），基本上程序员自己也能改好，如果这点你技术都没，还是回家种田去吧，？还有你说的那种方式，效率极低，美工要跟着程序员跑，或者程序员要跟着美工跑。

Answer 26

是啊。我也感觉控件时asp.net的一大 特色如果不用。、可惜可惜啊啊

Answer 27

还有 你如果有点经验的话，就算是用的服务器控件，生成的HTML代码，也不会对你的原有样式有影响，你可以看生成的代码，当然可能你滥用，那就另当别论了顺便说句，微软没这么低级

Answer 28

现在美工就是做一个html页面，然后我们套进程序中。

Answer 29

都什么年月了，还有人津津乐道于最后生成的HTML代码如何的"垃圾"，如何的"恶心".我是从PHP,ASP时代过来的，我知道程序员最需要的是什么:逻辑的简化！

Answer 30

说到最后到底是怎样好啊，我被你们弄晕了啊，
我也是。NET的，感觉用控件还好啊，
当然，一般情况自己能打的出来的就不用控件啊

Answer 31

按钮数据提交你不用服务器的按钮，难道用HTML按钮，回到ASP时代？

Answer 32

我现在做的就是数据提交不用服务器的button直接用html的submit.

Answer 33

那样还不如用Java来开发，.Net的优势就在于控件齐全。

Answer 34

推荐篇文章大家看看
http://www.cnblogs.com/JeffreyZhao/archive/2007/12/22/Experience-for-Asp-dot-net-and-WebForms-2.html

Answer 35

 本来 就是哪个语言都可以。若果最初学的不是ASP.NET，那么就会很清楚了

Answer 36

刚刚去实习，公司用的也是纯html标签，本来好迷惑的，现在清楚了不少啊！谢了……