前言：
还记得刚学ADO.NET的情景么？
还记得当年是怎么从ADO.NET被忽悠到用SqlHelper的么？
话说从入门到走上工作岗位那些年，我们就一直被纯纯地教导或引导，ADO.NET太原始，得封装成SqlHelper或DBHelper......
后来，这种思维一直深深就存在脑海里，并不知不觉中进入了潜意识，形成一种习惯。
在写框架的前几年，我也一直延续着这种思维，早期CYQ.Data的源码里，也有Sqlhelper,我也分享过Sqlhelper类的源码......
后来框架写久了，开始对框架的命名有讲究了，就默默低调的把Sqlhelper给改名了...
上个月的某一天，我给以前的同事传授知识时，不自觉的提到这个Helper悖论问题。
今天，无意中看到了这样的一篇文章，于是觉得可以分享一下自己的观点了：
文章里只有一个帮助类的代码，这里只截一小段：
这些年框架写多了，对面向对象相关的很多定义和使用，在潜意识里已经自有一套模式，以下分享两个小点：
1：定义Static变量需要考量的两个因素：内存和并发：
1：定义static变量：意味着该对象从始致终，都存在内存中，因此，你需要思考对象可预计或不可预计的大小，是否全局，若否，需要在何处需要将对象置Null？以便垃圾回收！
2：定义static变量：意思着在（Web）多线程环境下必然需要思考：是否有线程访问冲突？问题需要解决？需要Lock吗？需要双重判断？
若写代码时没有这两种考量，容易导致static乱用问题。
因此，上面的代码对Connection对象定义为static，明显错误有二：
1：资源只能用一个。
2：多线程下挂掉或抛异常是必然的，因为共用一个对象（场景如：A操作完Close，B操作到一半发现被Close了，好囧......）。
2：数据库操作类不应该为设计为static：
在现实的项目中，数据库的并发和事务是一件很自然就存在的事情。
因此：
1：并发的存在：意味着数据库操作类（ADO.NET）对象不能设置为static。
2：事务的存在：意味着数据库操作类不能将方法定义为static。
因此，数据库操作类合适的方式，应该设计成实例方式。
3：关于XXXHepler或XXXUtility的思维定义：
我们可以用Reflector在微软的内库里搜Helper或Utitliy结尾定义的类，可以随便挑着看：
结论都一个样：
1：这个类应该是个帮助类或定义为static类。
2：内部应该（或大部分）是静态方法。
悖论出来了：
我在园子里扫了一下，发现大部分的SqlHelper类或DbHelper在经过项目的实战后，都知道该转成实例方式提供。
可是，既然都转成了实例，为啥还叫SqlHelper或DbHelper？？？
为啥？为啥？为啥？独独就对SqlHelper这个特殊呢？（那是我们从小就被教坏了。。。）
总结：因果论：
因为：数据库操作设计不应该为Static，同时Helper后缀的不该设计为实例类。
所以：在数据库操作类设计里，SqlHelper和DBHelper不该存活。
于是：如果你有幸运看到这篇文章，在教导新人的时候......切记，切记！记得把他教坏，哈！！！