你的位置:首页 > ASP.net教程

[ASP.net教程]不该活着的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。

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

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

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

结论都一个样:

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

2:内部应该(或大部分)是静态方法。

悖论出来了:

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

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

为啥?为啥?为啥?独独就对SqlHelper这个特殊呢?(那是我们从小就被教坏了。。。)

 

总结:因果论:

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

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

 

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