LDAP C#验证用户名

LDAP C#验证用户名！只验证用户名，不需要验证密码！

上面的代码太乱了，由于字符串是不可变的，这里它又使用了多重串联，因此会在内存中创建三个不必要的字符串垃圾副本。
最好的办法是使用string.Format，因为它内部使用的是可变的StringBuilder，也为净化代码铺平了道路。

开发人员喜欢在方法的末尾加上异常处理的嵌套方法，如：
如果相同的异常被处理多次，上面的代码会发生什么?毫无疑问，性能开销将会剧增。
大部分开发人员更喜欢使用foreach循环，而无视for循环，因为foreach更容易使用，但操作大型数据集时，使用foreach已经被证明是代价高昂的，在下面的代码中，我同时使用for和foreach遍历相同的数据库，在图1中显示了两种循环方法消耗的时间。
图 1 for和foreach循环遍历相同数据库消耗的时间对比
　　从上图可以看出，foreach循环明显要慢一些，它消耗的时间几乎是for循环的两倍，这是因为foreach循环中的dt.Rows要访问数据库中的所有行。因此需要遍历大型数据集时最好使用for循环。
验证简单的原始数据类型大多数开发人员都不知道内置的验证原始数据类型的方法，如System.Int32，因此很多人都是自己实现的，下面就是一个自己实现的验证一个字符串是否是数值的代码：
它使用了try catch语句，因此不是最佳的做法，更好的办法是象下面这样使用int.TryParse： 
在上面的方法中，连接处理在最后一个代码块中被明确调用，如果发生一个异常，catch代码块就会执行，然后再执行最后一个代码块处理连接，因此在最后一个代码块执行之前，连接将一直留在内存中，.NET Framework的一个基本原则就是当对象不被使用时就应该释放资源。当你使用using代码块时，对象上的dispose方法将在执行退出代码块时调用，这样可以保证SqlConnection的资源被处理和尽早释放，你也应该注意到这个办法也适用于实现IDisposable接口的类。
声明公共变量听起来可能有点简单，但我们经常看到滥用公共变量声明的情况，先来看一个例子：

在上面的MyAccount类中声明了一个AccountNumber公共变量，理想情况下，AccountNumber应该是只读的，但MyAccount类却没有对它实施任何控制。声明公共变量正确的做法应该是使用属性

这里MyAccount类对AccountNumber公共变量实施了很好的控制，它变成只读，不能由调用者类修改。
利用System.Data.DataTable访问数据我常常看到开发人员使用列索引从数据库访问数据
按照这种写法，如果列顺序在SQL查询匹配数据时发生了变化，你的应用程序将会受到影响，正确的做法应该是使用列名访问数据

　这样的代码更加稳固，列顺序发生变化不会给应用程序造成任何影响，如果在一个地方使用局部变量保存列名更好，即使将来你的列名发生了变化，也不用修改应用程序代码。
我希望你能从自身和其他程序员所犯的错误中汲取教训，避免犯同样的错误，如果你对本文阐述的C#程序员常犯的7类错误持有不同的看法，欢迎发表你的意见和想法。
挺有用的，但是不得不指出，关于 for 和 foreach 是个超级大 Bug.
StopWatch 的计时是会累加的，而不会随着 Stop() 清空。所以哪个测试摆在后面，哪个测试的效率就低。而且还是低一倍。
实际上 for 跟 foreach 是没有很大的区别的，个人倾向于用 foreach.
另外，关于只读公有变量，还不如用 readonly。若用楼主推荐的方法，要是那个只读变量是个比较大的东西，每次实例化都赋值一次。性能哗哗哗地就下来了。
c#存在的意义，就是可以犯这些错，否则，c#不会有任何存在的意义。

这么一看，for和foreach那个不太对吧 关键还是看集合内部是怎么实现的...

1.string.Format应该比直接拼更容易出错，因为参数多的时候，特别是修改的时候，还得一个一个数到底是第几个，而且它还与真实需要{}的字符串冲窘态。
2.string.Format的效率比不一定直接拼高，因为它需要解析，会有内存占用倒是事实。如果真追求这些，可以这样像下面这样写(甚至用到unsafe)，可以把它包装为params函数调用
对于数组来说for确实比foreach高效，其实的就不一定了，要看数据结构的具体实现。如果不知道for为什么高效，还不如用foreach，比如下面的代码，虽然最终访问的是数组，但是foreach比这种for高效。
循环浪费的那点儿时间基本上不算什么，而且在以后改了结构之后foreach会自动适合。

来源：NBA视频在线