不该活着的SqlHelper和DBHelper

不该活着的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不该存活。

总结：

过程很友善，结论很无情！

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

关于文章被侵权问题：

@dudu，@博客园 文章被今日头条盗了，还没注明作者和来源，怎么弄它？：

​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。