这代码是从begenning asp.net 2.0 e-commerce in C# 2005上抄的吧！

试了一下代码,还是有错....

BLL.UpdateItem(Id, quantity)就这个，在BLL中怎么判断修改的是Quantity还是别的整数的字段?因为你传过去的是二个整数Id,和quantity

按照搂主的算法，每次都会把Product表中所有的数据算一次Rank，然后存到表变量中。这样是不是很影响性能呀？

--引用--------------------------------------------------
笑望人生: 对第六条不同意.
如果对一个xml文档不做架构上的修改的话，没有必要使用XmlDocument和XPathDocument，只读取xml文档内容的话应该使用XmlReader，速度最快。
同理，如果使用只进方式读取数据，应该使用XReader对象，如XmlReader,DataReader等。这样速度最快。
--------------------------------------------------------
兄弟你也错了，是xmltextreader

关于SQL2000的代码中有个问题， 在代码的最后#Product表示应该删除还是只删掉其内容即可呢？

概念性错误。。
三层是MVC 模型、视图、控制器。数据访问是从业务逻辑中扩展出来的。

小哥，上面的SqlServer2000存储过程，你最好测试一下，再发上来啊！虽然有点小错误，但是还是感谢你把心得写上来！

很好,谢谢

请注明选自.................

首先，强顶“双鱼座”；
博主说的确实有点不怎么样，但是一大片的人在顶啊，还说专业，等等，
有些东西是对的就是对的，不对就是不对了。
很赞成双鱼，逐条批驳有理有据，
大家就该那样，
一不要乱喊，
但也不要，你好我好，大家都好啊！

好的文章始终让人百读不厌！！顶，支持楼主！！！

It's very very good.
真的是非常不错，但是LZ的那个对搜索结果排序的算法，俺还是不明白啊

不错的一个存储过程,在本人的博客(http://blog.027idea.com)里也收集了一些数据库的技术文档,欢迎大家来查看.

针对几十万的数据好像很慢，根本不能用

timone^^^

每个人的技术知识水平不同，当然能看到的点以及关注的点也不一样！
昨天同事聊天听到的一句话，很适合，希望大家能思考一下
不以人废言，不以言废人

我哪个错误，不是编译错误，是执行的时候，我随便试个数据，就冒出一个很奇怪的问题，所以不得求救你，我是南昌的。。。谢谢

如果不愿意麻烦，可以发到我邮箱：luozhai714@163.com
非常感谢

就是这个存储过程
还有你哪个UDF，说老实话，我不是很明白
谢谢

我试了一下。。有个冒然的问题能否发个原码包给我
不好意思我的水平比较菜
QQ：358918610
随时在线
不盛感激！

我是个初学者,博主写的确实不错,在这里先谢谢,给我们这些初学者很大的借鉴
但更希望大家能够讨论,因为如果一味的支持,就不会完善,就有可能给初学者带来误导,毕竟初学者不太会判断,相信@双鱼座是善意的,这样对我们也是非常有帮助,如果说的不好,望大家勿怪

@马甲小同学
谁是愤青,谁是孔乙巳相信每个人都已经知道,不需要我说什么了。不过我真的希望你能够驳我，不论驳倒与否，而不是仅仅是骂街。
我技术高低其实并不需要任何证明。即使我想证明，这些入门文章根本证明不了的。请相信我是善意的。

要是指望这些来优化性能，简直是误人子弟啊！

@双鱼座
你小子是愤青 还是孔乙己啊 你说的那些 我全能驳倒 我只是懒得打字而已，楼主发个东西 只是给大家借鉴的 ， 任何事情都有两面性 ，需要自己去判断和根据实际情况去判断和采取不通策略 。你发这些东西 要证明你技术高吗？无聊

我觉得小的数据量用DataSet也无妨

kiler是高手 哈哈哈 支持啊你

关于通过静态类来访问APP.Config/Web.Config 的问题
我也是无意中在一篇外国文章看到的，也从来没有在其他地方看到过相关描述，昨天发了几个小时后，才觉得可能有点问题，现在看来是一个明显的错误了。多谢大家指点。

2. 尽量使用ExcuteReader来读取数据，ExcuteReader是效率最高的，在MicroSoft的PetShop 4.0全部数据访问都是用ExcuteReader来实现的，除非你对非连接有特殊要求（如 SmartClient智能客户端等）。

关于使用DataReader和DataSet不能觉得的说那个效率高，要看情况而定，比方说你执行一个批量数据操作，在这个操作中你要反复访问某些数据，你就可以预先将这些数据读取到DataSet里面，供接下来的操作反复使用。减少数据库的访问次数。

8. 通过静态类来访问APP.Config/Web.Config
我们有很多配置信息都是放在APP.Config/Web.Config，访问都会很频繁，这时建立一个静态类，所有的属性都通过静态类来访问，可以在一定程度提高性能，静态类只实例化一次，而APP.Config/Web.Config会产生很多IO操作。

对于一个好的架构而言，我甚至认为在Web.Config里面储存配置信息是一个不好的设计，因为你每一次改动配置都会导致Web Application重新启动。我觉得比较好的做法是把配置保存在自己定义好的xml文件里面。系统启动时将配置读入缓存，然后让缓存和配置文件建立依赖。这样就可以保证修改配置不会重起服务器了。

@阿瑞
知道，嘿嘿，只是想说明Length作用。

ps：看一遍楼主的随笔，再看一遍@双鱼座的回复，
感觉爽，模糊不清的东西，都体会出来了，谢谢二位：）

to Timone
通过静态类来访问APP.Config/Web.Config是完全没有必要的，你可以通过Reflector看一看System.Configuration.DefaultConfigurationSystem和System.Configuration.ConfigurationRecord两个类中的实现。其中已经根据配置的名称为关键字进行了缓存，否则也不会出现每次修改Web.Config文件的时候Web Application都会重新启动。

:)呵呵.

受教了，在大型应用上这些确实是非常有必要的。

还算说得过去，值得一看！

有些说法是不严密的。但是看一看还是有参考价值的。
顶个现。

有些道理,不过都是些细小的问题,希望能发些更有价值的.

我觉得楼主说的东西只能作为一种好的编程习惯去遵守，想要提高系统的性能，仅靠这点东西是远远不够的。系统性能高低主要还是靠良好的系统架构来保证。

我觉得写得蛮有道理的,大家要注意博主的标题"如何最大限度提高.NET的性能"。看仔细理解了再发表意见。再设计好架构的前提，再能注意到这些细节，岂不是更好吗？而对于文章内容中一些文字表述不是很确切，这点大家完全可以根据自己实际开发中的体会理解。何必这么鸡蛋里挑骨头。

对第六条不同意.
如果对一个xml文档不做架构上的修改的话，没有必要使用XmlDocument和XPathDocument，只读取xml文档内容的话应该使用XmlReader，速度最快。
同理，如果使用只进方式读取数据，应该使用XReader对象，如XmlReader,DataReader等。这样速度最快。

there is also an article about bulk editing in real world:
http://blogs.msdn.com/mattdotson/articles/490868.aspx

@双鱼座
大哥，楼主本来是好意。或许像你说的这样，不是很严谨，甚至有些地方有错误，但至少不是胡言乱语。
作为刚入门的开发者，不可否认楼主说的都是一些他们常见的错误或误区。能够对这些朋友有所帮助，也就非常有用了。
楼主第一次在博客园发帖子，支持一下，或许以后会更好的。
：）

应该有人记得20/80法则吧..
这些"小技巧"至多只能提升20%的性能, 关键还是要找到那个影响程序性能80%的瓶颈问题.
当然这些"小技巧"也是不能忽视的, Effective C#里面有很全面的讲解

我觉得很好，给出了一些可以参考的建议。
即使把大部分精力放在业务逻辑上，以上细节也不应该被忽视。
尤其对字符串处理问题深有体会。
堆 ，栈中 字符串处理消耗的资源是惊人的，有时甚至超过业务领域的资源消耗。

@Timone
可以扩展下分词方式

不太明白是上面功能 可以具体说下吗

再扩展下一次编辑 一次保存

虽然我不知道你从哪里抄来的，但是我仍然要告诉你，你文中的大部分内容不够严谨，甚至是错误的：
1）避免使用ArrayList。
不严谨。只有元素类型为值类型时才存在性能损失。

2）使用HashTale代替其他字典集合类型（如StringDictionary,NameValueCollection,HybridCollection），存放少量数据的时候可以使用HashTable.
错误。没有HashTable，只有Hashtable。观点也是错误，与第1）项相反了。

3）为字符串容器声明常量，不要直接把字符封装在双引号" "里面。
不严谨。虽然定义字符串常量是良好的编码习惯，但是与性能无关。通常编译器都会替我们做好。

4) 不要用UpperCase,Lowercase转换字符串进行比较，用String.Compare代替，它可以忽略大小写进行比较.
基本正确。之所以是基本，一是因为这样的写法对性能的提升极其有限，而优秀的程序员往往具有这样的优良的习惯。作为提升性能的一个原则，根本是小题大作。

5) 用StringBuilder代替使用字符串连接符 “+”，.
不严谨。如果仅仅合并两个字符串项，“+”的性能反而更优。

6)如果只是从XML对象读取数据，用只读的XPathDocument代替XMLDocument,可以提高性能
不够严谨。“读取数据”这个概念不清。采用XPathDocument还是XmlDocument不是依照“性能”来选择，而是根据“功能”来选择。

7) 避免在循环体里声明变量，应该在循环体外声明变量，在循环体里初始化。
错误，这里根本不存在性能问题，甚至可以说，在循环体内声明更佳。因为变量的作用域小了。这里不存在垃圾回收问题，因为用的是栈空间。

8) 捕获指定的异常，不要使用通用的System.Exception.
不严谨。这也不涉及性能，而是可以令程序更可读。

9) 使用Try...catch...finally时， 要在finally里释放占用的资源如连接，文件流等
不严谨。这也不涉及性能问题，而是泄漏问题。

10) 避免使用递归调用和嵌套循环，使用他们会严重影响性能，在不得不用的时候才使用。
错误。理由不够充分。递归往往令逻辑变成简单而令系统更稳定。当然，太深的递归会增加栈空间的边界检查和分配更大栈空间开销。但影响细微。

11) 使用适当的Caching策略来提高性能
正确，但是是废话。为什么是废话相信不用我说了。

相反，我非常赞同hal、NoMagic和阿武的讲法。
这样的文章连Dflying Chen都顶，非常让我失望。

虽然都是细枝末节的东西，不过也能体现出一个程序员的职业素养和态度。不错！

楼主说的东西基本上都提高不了多大的性能，更别说最大限度提高了。

其实往往影响1个系统的性能都是自己设计上的问题。而不是这些小技巧影响的。

不过楼主说的技巧还是值的看一看的，呵呵！！！

1、既然是批量更新，建议一次提交，而非采用success = success && BLL.UpdateItem(Id, quantity)的方式多次更新，这样会造成多次连接调用，在无内存池的情况下会降低程序性能。
2、success = success && BLL.UpdateItem(Id, quantity);只是表明更新的总体结果，其对于用户的提示在多数情况下会造成一种困惑，希望能够具体一些，例如：“某一条记录更新失败”，进一步的可以给出失败的大致原因。