不该活着的SqlHelper和DBHelper

前言：

还记得刚学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。

因此，数据库操作类合适的方式，应该设计成实例方式。

这里再补充一下，为什么不应该设计为static：

1：通过在static里方法产生实例，可以避免线程问题，但对象不能复用，事务没法用。

2：把对象提升为参数，外部实例后传入：能复用对事和事务，但根据业务场景需要不断增加重载方法，修改方法以适用，所以这种设计也不合理。

比如你需要增加参数来达到复用：执行的时候是否关闭链接、事务是否提交、参数是否清除、DataReader返回的参数重载等N种场景。

如果你说：你的业务场景就是不需要事务，场景相当简单，那我想，也不存在设计的问题了，爱咋咋的了......

3：关于XXXHepler或XXXUtility的思维定义：

我们可以用Reflector在微软的内库里搜Helper或Utitliy结尾定义的类，可以随便挑着看：

结论都一个样：

1：这个类应该是个帮助类或定义为static类。

2：内部应该（或大部分）是静态方法。

悖论出来了：

我在园子里扫了一下，发现大部分的SqlHelper类或DbHelper在经过项目的实战后，都知道该转成实例方式提供。

可是，既然都转成了实例，为啥还叫SqlHelper或DbHelper？？？

为啥？为啥？为啥？独独就对SqlHelper这个特殊呢？（那是我们从小就被教坏了。。。） 

总结：因果论：

因为：数据库操作设计不应该为Static，同时Helper后缀的不该设计为实例类。

所以：在数据库操作类设计里，SqlHelper和DBHelper不该存活。 

于是：如果你有幸运看到这篇文章，在教导新人的时候......切记，切记！记得把他教坏，哈！！！

原文地址：http://www.cnblogs.com/cyq1162/p/5745325.html

---

.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注