62,243
社区成员
发帖
与我相关
我的任务
分享看了ms的"开发高性能的 ASP.NET 应用程序"，想和大家讨论下
对于性能，我的想法是只要能有更好的方法开发高性能的应用程序，绝不用那些以牺牲性能为代价的方便的，现成的方法来快速实现。看了前面有个讨论asp.net性能的问题，有些兄弟就说为了使用强大的asp.netweb控件能快速的开发应用程序，损失些性能吧，也是一种选择，在下深以为不可取。明知有性能问题而不顾却去使用方便快速的方法，这不是一个好的开发人员的风格(除非真的不知道这种方法影响性能),我认为，开发程序是麻烦自己，让用的人更方便，而不是方便自己，让用的人麻烦
真正做过大型数据处理网站的兄弟都清楚性能的重要性，如果仅仅是为了方便快速开发而不顾性能，做出来的东西放在自己单机上运行就行了，因为放在internet就成了一堆垃圾了，除非还是就那么几个人访问。
1.避免到服务器的不必要的往返过程。虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。
通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。
2.在适当的环境中使用 ASP.NET 服务器控件。检查您的应用程序代码以确保对 ASP.NET 服务器控件的使用是必要的。即使它们非常易于使用，但是服务器控件并不总是完成任务的最佳选择，因为它们会使用服务器资源。在许多情况下，一个简单的呈现或数据绑定代入就可以完成任务。
(看了上面这两点，看来web服务器控件除了datagrid,datarepeate,datalist外，可以考虑全部都砍掉，除非我想偷懒，我就像ms搞出这些影响性能的web服务器控件东西出来干吗用，难道就像asp中的dtc控件，只是一个摆设而已)
3.只在必要时保存服务器控件视图状态，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。
(本来还以为这个功能不错，现在看来也是只在很有必要，非用它不可的情况下不得以而用之了)
4.不要依赖代码中的异常，因为异常大大地降低性能
(ms用了"大大"两个字，看来这东东也是花瓶，还是采用以前asp中的方法慢慢的用if来判断吧，除非我不管性能。)
5.选择适合页面或应用程序的数据查看机制。根据您选择在 Web 窗体页显示数据的方式，在便利和性能之间常常存在着重要的权衡。例如，DataGrid Web 服务器控件可能是一种显示数据的方便快捷的方法，但就性能而言它的开销常常是最大的。在某些简单的情况下，您通过生成适当的 HTML 自己呈现数据可能很有效，但是自定义和浏览器定向会很快抵销所获得的额外功效。Repeater Web 服务器控件是便利和性能的折衷。它高效、可自定义且可编程。
(本来还以为datagrid是个好东东，它确实好，就是开销是最大的而已，那还有什么好，估计微软又是拿它做花瓶，看来结合上面所说的1，2项，web服务器控件就只能下Repeater还可以用下了，不过Repeater还是便利和性能的折衷,看来为了提高性能，只能像asp一样手写table了，我不能因为方便而损失性能阿)
真正做过大型数据处理网站的兄弟都清楚性能的重要性，如果仅仅是为了方便快速开发而不顾性能，做出来的东西放在自己单机上运行就行了，因为放在internet就成了一堆垃圾了，除非还是就那么几个人访问。
1.避免到服务器的不必要的往返过程。虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。
通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。
2.在适当的环境中使用 ASP.NET 服务器控件。检查您的应用程序代码以确保对 ASP.NET 服务器控件的使用是必要的。即使它们非常易于使用，但是服务器控件并不总是完成任务的最佳选择，因为它们会使用服务器资源。在许多情况下，一个简单的呈现或数据绑定代入就可以完成任务。
(看了上面这两点，看来web服务器控件除了datagrid,datarepeate,datalist外，可以考虑全部都砍掉，除非我想偷懒，我就像ms搞出这些影响性能的web服务器控件东西出来干吗用，难道就像asp中的dtc控件，只是一个摆设而已)
3.只在必要时保存服务器控件视图状态，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。
(本来还以为这个功能不错，现在看来也是只在很有必要，非用它不可的情况下不得以而用之了)
4.不要依赖代码中的异常，因为异常大大地降低性能
(ms用了"大大"两个字，看来这东东也是花瓶，还是采用以前asp中的方法慢慢的用if来判断吧，除非我不管性能。)
5.选择适合页面或应用程序的数据查看机制。根据您选择在 Web 窗体页显示数据的方式，在便利和性能之间常常存在着重要的权衡。例如，DataGrid Web 服务器控件可能是一种显示数据的方便快捷的方法，但就性能而言它的开销常常是最大的。在某些简单的情况下，您通过生成适当的 HTML 自己呈现数据可能很有效，但是自定义和浏览器定向会很快抵销所获得的额外功效。Repeater Web 服务器控件是便利和性能的折衷。它高效、可自定义且可编程。
(本来还以为datagrid是个好东东，它确实好，就是开销是最大的而已，那还有什么好，估计微软又是拿它做花瓶，看来结合上面所说的1，2项，web服务器控件就只能下Repeater还可以用下了，不过Repeater还是便利和性能的折衷,看来为了提高性能，只能像asp一样手写table了，我不能因为方便而损失性能阿)
...全文
请发表友善的回复…
发表回复
rijcm 2005-01-25
- 打赏
- 举报
学习：)
tbchinese 2005-01-25
- 打赏
- 举报
绑定～
FJGoodGood 2005-01-25
- 打赏
- 举报
最后总结一句：
把关注点放在软件的体系结构、开发效率、系统可扩展性上，而不是局部的性能优化。
把关注点放在软件的体系结构、开发效率、系统可扩展性上，而不是局部的性能优化。
programmer11 2005-01-25
- 打赏
- 举报
我顶我顶我顶顶顶
Libra_Chen 2005-01-25
- 打赏
- 举报
我晕。那么大型网站用服务器控件的话就性能来说asp.net未必比asp好了？如果不用服务器控件，那从编程角度讲asp.net也没有那么多优势了……矛盾啊。
deverxp 2005-01-25
- 打赏
- 举报
以前给公司做的一个网络进销存网站，200来人使用，经常被同事埋怨速度慢，当然有时候是因为网络不稳定的原因，有时确实是因为写的代码性能不高的原因。
所以很多时候我就在想，只要性能高，就算代码再没有什么结构性，我都会去写。实在被那些同事埋怨的头痛不已。
所以很多时候我就在想，只要性能高，就算代码再没有什么结构性，我都会去写。实在被那些同事埋怨的头痛不已。
deverxp 2005-01-25
- 打赏
- 举报
to cat_hsfz()
不知道这位兄弟有没有看清楚我的问题，那些对于性能的影响和建议都是微软的一篇文档里摘抄的，如果照你这样说，难道微软还建议我们破坏.net体系结构来实现最优的性能，不大可能吧。
其实对于我的这些想法，更适合那些实际参加过或正在参加web项目开发(比如网络进销存类或oa类)的兄弟来讨论。
对于c/s结构，对于过分追求性能实在不可取，所以大家都偏重追求严谨的项目和代码结构。这也就是为什么做过oo的人来做web开发的时候，这种习惯照样保留下来。
由于b/s结构特殊性，还要兼顾网络状况。当你一味追求你的结构完美过分依赖服务器控件到最后做出来的东西被客户时常埋怨的时候，你觉得你做出的这个网站是一个成功的产品吗？我觉得这样的网站只能用叫好不叫座来形容.
我上面也说过,现在写程序不是为自己写,不是要实现代码艺术的时候,而是要考虑到市场需要,所以我的论点大多从实际应用出发,而不是纯粹的讨论代码结构.如果纯粹的讨论代码结构，这位兄弟则说的很对
当然不能完全摒弃web服务器控件，像ms的treeview,验证控件，都是可以提高很多效率的，而且它们在支持dhtml的浏览器上都能支持的很好。
不知道这位兄弟有没有看清楚我的问题，那些对于性能的影响和建议都是微软的一篇文档里摘抄的，如果照你这样说，难道微软还建议我们破坏.net体系结构来实现最优的性能，不大可能吧。
其实对于我的这些想法，更适合那些实际参加过或正在参加web项目开发(比如网络进销存类或oa类)的兄弟来讨论。
对于c/s结构，对于过分追求性能实在不可取，所以大家都偏重追求严谨的项目和代码结构。这也就是为什么做过oo的人来做web开发的时候，这种习惯照样保留下来。
由于b/s结构特殊性，还要兼顾网络状况。当你一味追求你的结构完美过分依赖服务器控件到最后做出来的东西被客户时常埋怨的时候，你觉得你做出的这个网站是一个成功的产品吗？我觉得这样的网站只能用叫好不叫座来形容.
我上面也说过,现在写程序不是为自己写,不是要实现代码艺术的时候,而是要考虑到市场需要,所以我的论点大多从实际应用出发,而不是纯粹的讨论代码结构.如果纯粹的讨论代码结构，这位兄弟则说的很对
当然不能完全摒弃web服务器控件，像ms的treeview,验证控件，都是可以提高很多效率的，而且它们在支持dhtml的浏览器上都能支持的很好。
pray1997 2005-01-23
- 打赏
- 举报
为什么总把asp.net看成是与asp截然不同的东西，asp具备的优点asp.net全都具备，不是吗。好，既然说道服务器控件影响性能，你大可以用以前asp的方式来写asp.net，那么性能谁高呢？服务器控件只不过是asp.net提供的另一个选项，没有人强迫你去用它，不喜欢大可以用asp的方式，用servelet的方式,用jsp+beans的方式，都可以。只是你自己在开发过程当中来衡量，衡量代码工作量，开发周期，程序性能和以后的维护代价
cat_hsfz 2005-01-23
- 打赏
- 举报
不知道楼主是否有OO的开发经验，其实ASP.NET总是让大家产生大量的歧义，正如我在此贴所说：
http://community.csdn.net/Expert/topic/3138/3138937.xml?temp=1.296633E-02
歧义的问题就在于，ASP.NET的程序员，一半来自无Web开发经验的C++，另一半来自无OO开发经验的ASP，而ASP.NET则是集成Web开发和OO，于是ASP程序员总是质疑.NET Framework的对象模型（否则就是滥用对象），而C++程序员则不停的提HTTP/HTML/Javascript等问题。
http://community.csdn.net/Expert/topic/3138/3138937.xml?temp=1.296633E-02
歧义的问题就在于，ASP.NET的程序员，一半来自无Web开发经验的C++，另一半来自无OO开发经验的ASP，而ASP.NET则是集成Web开发和OO，于是ASP程序员总是质疑.NET Framework的对象模型（否则就是滥用对象），而C++程序员则不停的提HTTP/HTML/Javascript等问题。
cat_hsfz 2005-01-23
- 打赏
- 举报
实际上很多人的问题来自于对服务器控件的误解！
服务器控件的原本目的，我的看法是为了封装的需要。在ASP的年代，所有东西都会插手Request和Response，到处都是全局变量，开发出来的东西一旦大到一定程度就无法维护。而ASP.NET的服务器控件正是为此事而产生的——把Request和Response都分割到对象模型的细节上面，由于由全局变量转变到对象模型，那么每一方面的读写权限都能够明确划分，以确保正交设计。所以我的极端说法就是——如果你的是没有“设计阶段”的“快速开发”，那就应该像ASP那样老老实实写代码，只用HTML控件不用服务器控件。
服务器控件，是一个为了设计而诞生的东东，或者更加细节一点，它服务于的设计主要是为了日后维护方便。所以，如果你不打算做自己的服务器控件，那么几乎没必要去碰原有的服务器控件，原有的服务器控件的主要作用是给你继承或者自定义服务器控件contain的。
题外话，这个事情就算笔记本电脑生产商对于MS对Tablet PC的定位误解一样——大多数公司都去生产只有屏幕和完全用笔输入的Tablet PC，结果大多数用户都觉得没有了键盘很不方便；只有Acer明白Tablet PC应该是像普通笔记本一样有键盘的，只不过在需要的时候可以把屏幕翻过来盖在键盘上，也就是说用户有两种选择——既可以像普通笔记本电脑一样使用，也可以缩小空间但是只用笔输入。
服务器控件的原本目的，我的看法是为了封装的需要。在ASP的年代，所有东西都会插手Request和Response，到处都是全局变量，开发出来的东西一旦大到一定程度就无法维护。而ASP.NET的服务器控件正是为此事而产生的——把Request和Response都分割到对象模型的细节上面，由于由全局变量转变到对象模型，那么每一方面的读写权限都能够明确划分，以确保正交设计。所以我的极端说法就是——如果你的是没有“设计阶段”的“快速开发”，那就应该像ASP那样老老实实写代码，只用HTML控件不用服务器控件。
服务器控件，是一个为了设计而诞生的东东，或者更加细节一点，它服务于的设计主要是为了日后维护方便。所以，如果你不打算做自己的服务器控件，那么几乎没必要去碰原有的服务器控件，原有的服务器控件的主要作用是给你继承或者自定义服务器控件contain的。
题外话，这个事情就算笔记本电脑生产商对于MS对Tablet PC的定位误解一样——大多数公司都去生产只有屏幕和完全用笔输入的Tablet PC，结果大多数用户都觉得没有了键盘很不方便；只有Acer明白Tablet PC应该是像普通笔记本一样有键盘的，只不过在需要的时候可以把屏幕翻过来盖在键盘上，也就是说用户有两种选择——既可以像普通笔记本电脑一样使用，也可以缩小空间但是只用笔输入。
slhuang 2005-01-23
- 打赏
- 举报
关注。
楼上某位某观点说得不错。
楼上某位某观点说得不错。
xxuu503 2005-01-23
- 打赏
- 举报
什么系统那么耗资源，真的那么耗么？又不是像csdn一样！动不动就上不去了。
对于mis和erp，为小公司作的，多不过七八十个同时访问。耗不了那么多资源！
大公司更喜欢java，让javas折腾吧。不过好像java的服务器都很贵。
对于mis和erp，为小公司作的，多不过七八十个同时访问。耗不了那么多资源！
大公司更喜欢java，让javas折腾吧。不过好像java的服务器都很贵。
ldljlq 2005-01-23
- 打赏
- 举报
两者的平衡，各取所需。
Ivony 2005-01-23
- 打赏
- 举报
ASP是一种解释生成Html的Script，而ASP.net只在Render事件中，才将所有的代码全部处理出来。
在ASP.net中，是不应该使用传统的ASP的方法撰写网页的，CodeBehind或者AllInPage中最好只选择一种，否则代码就会比天书更难看明白。
WebControls和HtmlControls其实都是Controls，不同的是，WebControls的名字与WinForm中十分类似，这将有利于程序员将代码从Application搬运到Web上面来，但实际上这并不是一个好的解决方案，它顶多能让程序员使用熟悉的名字，但这是以极大的性能开销为代价的。WebControl默认全部都开启了ViewState，另外他们还必须放在runat="server"的form中，无论是你否需要提交或者存在服务器事件。这样做的好处是让WebControl在浏览器上执行得像在Win32环境下一样。但这是不可能的。
如果你对HTML很熟悉，使用HtmlControls是不二的选择，HtmlControls可以明确的知道将生成的HTML代码是什么样子。同时，HtmlControl也没有WebControl那么多古怪的限制。
微软的数据绑定控件全部过分傻瓜而效能低下，微软试图在设计器中搞定一切，但这样做的代价就是效率和呆板。
在ASP.net中，是不应该使用传统的ASP的方法撰写网页的，CodeBehind或者AllInPage中最好只选择一种，否则代码就会比天书更难看明白。
WebControls和HtmlControls其实都是Controls，不同的是，WebControls的名字与WinForm中十分类似，这将有利于程序员将代码从Application搬运到Web上面来，但实际上这并不是一个好的解决方案，它顶多能让程序员使用熟悉的名字，但这是以极大的性能开销为代价的。WebControl默认全部都开启了ViewState，另外他们还必须放在runat="server"的form中，无论是你否需要提交或者存在服务器事件。这样做的好处是让WebControl在浏览器上执行得像在Win32环境下一样。但这是不可能的。
如果你对HTML很熟悉，使用HtmlControls是不二的选择，HtmlControls可以明确的知道将生成的HTML代码是什么样子。同时，HtmlControl也没有WebControl那么多古怪的限制。
微软的数据绑定控件全部过分傻瓜而效能低下，微软试图在设计器中搞定一切，但这样做的代价就是效率和呆板。
Ivony 2005-01-22
- 打赏
- 举报
極端的追求性能我想是片面的﹐樓主是否有考慮到開發效率﹐其實我也不很喜歡用webcontrol﹐但我在性能和效率的折中點上會適當考慮使用webcontrol﹐其實我是極少用datagrid的﹐相反卻喜歡自己去拼湊﹐原因就是我認為我自己拼湊的效率跟直接用datagrid差不了多少。
应该说，自己拼凑比DataGrid快得多。
应该说，自己拼凑比DataGrid快得多。
yizhixiaozhu 2005-01-20
- 打赏
- 举报
Up
代码蜗牛sky 2005-01-20
- 打赏
- 举报
我们应该平行两方面的因素
hubinasm 2005-01-20
- 打赏
- 举报
MARK
mba9001 2005-01-20
- 打赏
- 举报
不错，再看
极客行天下 2005-01-20
- 打赏
- 举报
以前也看过该文章，我觉得在平时开发的过程中灵活掌握。
加载更多回复（41）
