为了账号安全,请及时绑定邮箱和手机立即绑定

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了,好囧......)。

发现有超过一半的人分不清文章的逻辑,所以加点无敌分隔线,以便后续来者看的简单些。

----------------------------------以上内容只是引子和分享点知识,和标题要陈述的内容无关--------------------------------

评论的问题在于:

A:只针对引子1去发表意见,而忽视重要的论据2和3,没有人针对论据2和3去评论?

B:把范围扩大到Static和Helper去评论,不知道文章说的是sqlHelper或DBHelper,是针对数据库的么?

----------------------------------下面的2-3才是针对标题的论据---------------------------------------------------------

2:数据库操作类不应该为设计为static:

在现实的项目中,数据库的并发和事务是一件很自然就存在的事情。

因此:

1:并发的存在:意味着数据库操作类(ADO.NET)对象不能设置为static。(把特意把对象加粗,这里不是说方法)

2:事务的存在:意味着数据库操作类不能将方法定义为static。(这里才是说方法)

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

进一步补充解释:

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

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

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

再简化解释:

1:不该将对象定义为静态(这个1的引子可见)

2:不该方法定义为static(因为要操作事务共享,进一的论据是场景会引发重载过多,导致设计不合理)

如果还是看不懂。。。多看几遍吧,这里是重要的论据。

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

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

结论都一个样:

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

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

悖论出来了:

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

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

应该改名的!

为啥?为啥?为啥不改名呢?(那是我们从小就被教坏了。。。)

因果论:

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

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

 

总结:

过程很友善,结论很无情!

世事无绝对,存在即合理,人生的理由除了应不应该,还有喜不喜欢,值不值得,习不习惯,所以,楼下都在为它找一个合理存在的理由。

 

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消