asp.net优化探讨系列(2)

    上一篇有同学说我说了等于没说,呵呵,如果您有高见,欢迎您跟帖,不要说那些无意义的“说了等于没说“之类的话,要知道并不是所有的人都像您那样强啊!同时这篇会结合一些小例子,特别小的例子,呵呵!
    
数据访问相关场景一:新增加记录
我们在设计增加一条记录的时候,有时采用主键自增,有时在程序中生成,一般是return max(id)+1
那么,我们就要先获取id,然后在插入记录,这是两次数据库的访问了!那在其他更加复杂的场景里面,我们也这样增加数据库之间的访问次数,就有一定的性能影响了!所以对于类似的或复杂的我们可以用存储过程来代替!
场景二:查询(说说废话)实在不想用实体集和返回,您的第二选择也不该是DataSet,而是DataReader!我想真的在用DataSet特性的也没多少吧!呵呵!记得使用using(),方便,放心!不是每个人写的代码都可以让人放心的,包括我!
场景三:分页:老实说像我这样的菜鸟常看人家写的代码,发现很多完整的例子,类似”xxx"管理系统,里面的数据显示很多情况都是直接拖个GridView绑定上数据,然后设置个分页属性,就ok了,可事实上这样行的通吗,撇开大数据量不谈,在这个分页的基础上还要有ViewState的支持,上次已经说了,它确实是个很强大的东西,用好了会很强,因为asp.net控件保存状态大都依靠它!可是大量在服务器往返,坏处就很明显了!所以实现自己的分页逻辑,最好还是用存储过程,性能是很好的!
缓存场景一:页面级别的缓存 : <%@ Page OutputCache VaryByParams="none" Duration="300" %> 意思很明了,缓存5分钟,如果在5分钟内访问该页,都是从缓存中访问,和访问静态页面差不多!
场景二:asp.net级别缓存:对于一些访问频度高并且更改率低的数据,我们大可以缓存起来,从缓存里面访问,从而减少访问数据库的次数,降低数据库压力!(一般我自己会将缓存写成可配置的,然后根据配置文件来决定要不要缓存,比较灵活,这个是题外话,呵呵)。
ViewState该有他的一席之地,呵呵,我们也不必那么狠,直接在web.config将它禁掉,可以在访问平度高的页面禁掉,因为确实很吃服务器,呵呵,那么在写后台的时候,它的优势就可以发挥出来了,我们大可以发挥asp.net的”优势“,拖拖拉拉,然后绑定数据,包括数据的更新修改!因为毕竟后台不想前台那样要承受高访问量!而且我们还可以通过一些手段来压缩它,从而减小其大小,效果是很明显的!所以可以适当的用
我一直相信积累可以长知识,所以都是从一些所谓低级别的知识点说起,但是也不是所有人都能好好掌握,所以希望大家能自己知道的技巧分享出来,而不是不削地说”说了等于没说,首页缺少管理等”讽刺的话,我想你也不是生来就是高手吧,新手就不能发自己的想法在首页吗,而且这是经过自己思考的,起码我有在想!言语可能不当,如有错语,请多包涵!
posted @ 2008-01-15 17:30  Awen  阅读(2507)  评论(16编辑  收藏  举报