为什么我的项目经理说要少用服务器控件，有什么好处？？

服务器控件需要频繁的回发，所以性能上会降低，再者页面会有闪烁感。html控件使用脚本进行控制，减少了回发

因为WEBCONTROL对资源的消耗比较大。不过，WEBCONTROL还是有很多优点的，除非情非得已，还是使用WEBCONTROL比较好。比如，一个项目，可能开发的时候是多人的，实现代码管理的方式最好就使用虚拟占点了，事实上，很多新建的WEB项目都是虚拟站点的，如果要把项目复制到一个跟站点下使用，那么，牵涉到相对路径、绝对路径的问题，比如IMAGE的SRC问题，如果用WEBCONTROL，可以巧妙的使用~来表示虚拟路径的，这是HTML控件不具备的（除非把HTML控件RUNAT=SERVER，那这样与使用WEBCONTROL又有多大的区别？）当然，有个比较严重的问题就是DATAGRID的分页功能，当数据量非常多的时候，千万不要用，还是使用手动的好，我现在都要求凡是使用DATAGRID的地方，禁止使用分页功能。具体如何，看你对.NET的掌握如何，然后如何去说服你的项目经理了。

如果一个页面就是显示一个表格，那用datagrid和用HtmlTable（用foreach循环输出表格）在性能上有区别吗？？

服务器控件处理的时间要比HTML时间长得多,所以对应用程序性能有很大影响.如果能用HTML,就尽量不用服务器控件.

我说的不光是datagrid控件，这个项目经理，说：“总之尽量少用服务器控件，因为这种控件总会引起回发，尽量用js在客户端完成”。可是我看他写的一些js的代码有好多却是这样的：document.getElementById("iFrame1").src="DeleteTemplate.aspx?templateID="+ID;
self.document.location.href = 'templateManage.aspx';这样不也进行回发了吗，也从客户端和服务器端进行了往返，为什么不用一个服务器控件（Button）在click事件中写？？反正也是往返一次，这样而且还可以少一个DeleteTemplate.aspx页面！！！

使用客户端控件的话，1、性能比服务器端控件要高
2、可以基于以前的ASP开发。
3、所有页面代码可以打包到类库里面，直接Response出来。便于代码的积累。
如：论坛、新闻更新系统等，调用一个DLL就可以生成了。

可是用datagrid和protected System.Web.UI.HtmlControls.HtmlTable TB;到底会有什么区别？不都是在服务器端完成吗？

实在在意资源还不如使用动态生成HTML页面的技术
每过10分钟生成一次静态页面，数据更新不频繁的一个小时一次都可以。
我们网站就是自动生成静态的。www.5617.com

个人感觉这个项目经理有点矫枉过正了
这样的代码很难维护
根本没有体现出ASP.Net的优势
还不如索性用ASP
对于DATAGRID，如苯牛兄说，只要限制它不分页（自己控制分页），还是可以的
我怀疑这个项目的可维护性

不支持你的项目经理，一定是对.net认识不深或不太认同。
支持闭关的观点！

to：caoker2000(曹轲)我并没有不干呀，这是想看看大家的观点，总是听别人，让怎么干就怎么干，还提高什么？讨论一下不好？

同意～
brightheroes(闭关|那一剑的风情)

就算懂也是用asp的思路来作.net的东西

什么项目经理嘛，BS
那还要.net干什么

你们的经理脑部受过伤，要原谅他。.net如果用了服务器控件就占用的大量资源，就会无法使用吗？那微软开发这个垃圾做什么？没有了服务器端的控件，那ASP。NET还有什么优势？直接用ASP呀！JS那个东东注定是要被淘汰的，（什么？有人用鸡蛋打我？我跑！）为什么？你没听过VS。NET2005要在编译时决定是用WINFORM还是WEBFORM吗？那你把JS放在WINFORM上我看看？

全用js做好了，你经理以前做asp的吧，告诉你老板炒他鱿鱼

你们的经理从那里看到的啊。尽量少用也行，总不能把循环写table代替了datagrid吧。
涉及到要后台asp.net代码操作的一定要用服务器控件。不涉及到的可以不用而且最好不用。
比如你有个label，要作为一个固定文本提示用，这时候你完全可以不用服务器控件。相反，如果你要在asp.net中更改这个文本，你就要用服务器控件了。

能不用服务器控件尽量不用服务器控件，主要是为了减少回发，和减少对服务器资源的占用，
但用服务器控件的好处是条理清晰，处理方便．
所以要权衡两者的得失，不要像你的经理的代码那样，是完全的asp的方式．
但比方．如果用<a href ='www.csdn.net'>就可以，肯定不用linkbutton．

哈哈!那就是用asp好了，不要使用.net
现在网络速度都很快了，不需要台节省资源
除非做大数据处理，才考虑这些问题。
如果像你们项目经理说得那样的话，我曾经做过上万条的数据显示，是用类似DataGrid插件的，而且比DataGrid还复杂，那是不是就是错误的呢？
我们应该根据实际情况

如果按照你的说法。NET快速开发的特性还不没拉！真的不如用ASP这个垃圾工具！

服务器控件带来过多的postback,如果是基于WAN的,建议少用.避免并发数量增长后带来的瓶颈.如果是基于LAN的,只要不是静态显示,都可以用服务器控件,因为lan内用户数量规模有限.这时候runat=server逻辑清晰的好处可以充分发挥.

你们经理说的没错，跟我的想法一样，他说少用又没说不用服务器控件是用服务器来生成HTML+JS 不如自已写的HTML+JS
熟练的使用js+html是非常有必要的，程序做出来更轻灵更高效，也有利于提高水平积累经验，你会觉得更得心应手那些只知道拖拖服务器控件的人，你看看他的精神状态就知道了,张口就骂，这种人浮躁冲动，怎么会有好的想法做一个好的程序员呢

个人感觉这个项目经理有点矫枉过正了
这样的代码很难维护
根本没有体现出ASP.Net的优势
还不如索性用ASP
对于DATAGRID，如苯牛兄说，只要限制它不分页（自己控制分页），还是可以的
我怀疑这个项目的可维护性
=============================以上所说的才是对的.

那该项目使用asp.net是对技术的浪费,用asp就足够了

少用服务器控件就会导致asp.net不如asp? 居然有这么理解.NET技术的
.NET的控件工具箱里就提供HTML控件与服务器控件两种选择，这样说来都是多余的了？
对于一些仅在客户端交互的网页部件一定需要用服务器控件吗？就象项目经理的那两句代码，
document.getElementById("iFrame1").src="DeleteTemplate.aspx?templateID="+ID;
self.document.location.href = 'templateManage.aspx';
一个是用控制框架页面，这个有必要用到服务器控件吗？一个是一个简单的页面跳转，这个也有必要用到服务器控件吗？.NET的内涵不仅仅是使用服务器控件那么简单，不是少用服务器控件就等于技术差了就不如用ASP了，.NET还能做很多ASP不能做的事他只是说适当的少用，哪些地方要用哪些地方不用当然要根据情况灵活的掌握，有时候访问量很大的网站，每个客户多占用一点资源积累起来就是一个很可怕的数目，少用服务器控件避免不必要的提交到服务器的过程减少服务顺口的资源占用有何不可呢，在很多优化ASP.NET性能的文章里都提到少用服务器控件啊

同意 hubinasm(火星撞地球之闭关修炼)

WEB控件的生命周期里视图占了很多资源,建议用WEB控件不建议用视图

to fhuaxyue() ( )document.getElementById("iFrame1").src="DeleteTemplate.aspx?templateID="+ID;
self.document.location.href = 'templateManage.aspx';想实现的功能是：点击一个按钮删除ID所指定的记录
这里的意思是：
第一句：在DeleteTemplate.aspx对数据库进行操作，删除ID所指定的记录
第二句：刷新'templateManage.aspx'页面（该页面用来显示所有记录）为什么要用js这么写，不就是asp的思路吗？直接用服务器控件（Button）不就可以了，在click中操作，还可以省调DeleteTemplate.aspx页面，这里就应该用服务器控件，我觉得！！

大家说的都很有道理
不过能不能详细一点说datagrid如何用手动分页啊
能详细一点吗?
小弟我是初学的
谢谢!

to niunj() 看看这个书：构建web解决方案——应用ASP.NET和ADO.NET

同意fhuaxyue() 的说法，很多公司内部软件都涉及到大量的客户端数据操作，减少WEB控件的使用可以减轻服务器的压力，虽然在实现上相对难一点、复杂一些，但企业可不这么想，毕竟升级服务器花的钱更多。做软件的不是应该为客户多考虑一些吗？如果只是考虑自己写起来方便，是不是太自私了。

我看你还是用ASP算了，那样会更好点...

SB一个,对新技术既然持支持态度就要真正的用它.连DG都不用,叫它还是用ASP写算了.页面上一堆JSP代码.那算什么啊...还不如用VIEWSTATE.
我们曾经写过一个CRM系统.就是整个系统的页面都是HTM的.用HTC访问WEBSERVER,得到其返回的XML格式的数据再用XML.DOM将数据通过用JAVASCRIPT写成的客户端的DATATABLE对象将数据放入表格当中,每次只取一页数据,并可以翻页,完全有了DATAGRID的功能,这样页面的确是不闪,可是单个页面的代码写起来太麻烦了.而且代码特别多.一点儿类的概念都没有.全是引用JS文件.总之不太爽..出了错改起来更是不爽.

看来你的项目经理是从asp转过来的，还没有理解aspnet。好多时候不回发服务器根本是不可能的，datagrid有时是不好用可是比你写table效率是快多了
我觉得在没有必要回发的地方应少使用服务器控件，必要的地方还是大胆的使用，现在的服务器没有那么弱的。
还有就是服务器控件也未必全会引发回发，设置autopostback属性就是了。
我以前的老板还让我们不要使用js客户端脚本呢？他们不懂时就是这么可笑。
问问他的理由是什么，再自己想想他说的是否正确，人最重要的是有自己的思想，而不是人云亦云。

看了大家的发言，我总觉得不爽！
1、如果对性能有要求的话，当然考虑不用aspx等，主要原因很多人都说了，aspx是在服务端执行完后在生成（html+js)返回到Ie来执行的，是大量占用服务端资源的，而且对页面控件状态把握不好，当大量同时访问量时，服务端往往服务不了而形成“该页无法显示”等错误，对Grid而言，由于采用较费时费资源的fill方法，当访问数据较大(超过20万以上，即使分页）也会出现性能问题导致时间等待过长或死机，这些都是目前aspx遇到的基本问题，当然，这种技术也是第一次推出来，相信M$会逐渐解决的！是否大量用服务器控件：1、如果同时有大量数据访问2、数据量大，这样用aspx是不妥的！
2、之所以出现aspx，主要还是开发效率的问题，如果某公司对js非常NB，很多都写成htc等组件封装，这样开发效率比使用aspx要高的多，如我们现在做了客户端的dataGrid,tree等，效率比服务端的快多了（当然还没M$稳定，且功能也没那么强，这些只是时间问题）
3、开发方式问题，用aspx往往被人成为非专业开发，这种开发方式往往逻辑不清晰，不能有效的分层，对中大型应用在结构上是致命的。
4、发展问题，如果.net以后解决了上述问题，这样采用也相信是中小型应用！

是啊，我昨天刚试过，从数据库里读出数据放在dataset的table里，然后用for语句从dataset
里读出3000条数据，写出一个table，再response.write出来，居然用了15秒，而且cpu占用率达到100%，我的可是双cpu服务器啊！！！而把dataset赋给datagrid只用了4秒！！！

对js运用较多时，很多都已经是封装成为了htc或公用的js了，这样可以做到如下通用
1、页面生成；（能到80%-95%生存，然后美工美化就ok了
2、校验通用；除了特复杂的或需要服务端校验（主要采用初始客户端控件时动态附事件、方法，属性等，然后系统自动调用来实现类型、长度、特性表达等校验）
3、增、删、改生成xml数据通用，这样，你仅需要关心后端逻辑层问题了
4、如datagrid或tree等现在也是htc来通用解决，你需要配置sql然后传参数就ok了
5、特定控制当然需要写一定js了，这些是不可避免的。
6、我们用.net主要是在后端实现1、大量实现特定功能的dll 2、逻辑层（1来支持2）这样开发仅需要考虑的是2，也就是说一个系统，最综需要解决的是业务逻辑层，这是关键之关键
7、架构如下
htm(js) + xml(通过xmlhttp来send) + aspx (仅后端解析和转换，功能同web service的代理）+ 逻辑层 + 通用dll(如数据层、操作服务等等)
发此贴的同时，真诚请教各位，我们这种开发模式有什么缺点?

具体怎么做和开发人员的技术有关系。
对js很熟悉的人当然很排斥服务器控件了，我们有个项目就是全部使用的html控件，写大量的js代码，的确是非常难以维护的，修改起来十分麻烦。使用服务器控件太多又很占用服务器资源，而且页面闪烁感很明显。给客户的感觉很不好。所以我的观点是在需要的时候才用服务器控件，比如TreeView，使用js生成的话很麻烦，而且代码难维护，所以就使用ms 的TreeView，直接用c#生成Tree，操作节点使用js来控制。

回发会不会影响性能, 我觉得关键还在ViewState的数据量和Page_Load方法上,
如果它的数据量极少并且在回发的时候Page_Load做极少的事情, 那么回发也没什么关系.
要让页面的_ViewState的数据量尽量最少的情况下保留asp.net的功能. 这个就要看各位使用asp.net的经验了.http://www.fjprint.com/ 就控制了ViewState的数据量, 大家可以看看页面源码.

调试易

为什么我的项目经理说要少用服务器控件，有什么好处？？

解决方案 »