還記得剛學ADO.NET的情景麽?還記得當年是怎麼從ADO.NET被忽悠到用SqlHelper的麽?話說從入門到走上工作崗位那些年,我們就一直被純純地教導或引導,ADO.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了,好囧......)。
發現有超過一半的人分不清文章的邏輯,所以加點無敵分隔線,以便後續來者看的簡單些。
----------------------------------以上內容只是引子和分享點知識,和標題要陳述的內容無關--------------------------------
評論的問題在於:
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,@博客園 文章被今日頭條盜了,還沒註明作者和來源,怎麼弄它?:
http://toutiao.com/i6315940257556595202/