我本不是個好爭之人,但在技術(shù)上我從來都是表達自己的想法而后快.
記得剛接觸一期,我就覺得那里有對頭.隨著時間的推移,我才感覺到原來是Asp.net程序員在開發(fā)的過程常會出現(xiàn)的錯誤使之(先這樣認為).
整個項目采用的是后臺實現(xiàn)業(yè)務邏輯和數(shù)據(jù)訪問;這就出現(xiàn)的SQL語句和業(yè)務邏輯混合在一起的大問題.(會出那些問題呢?)
(1)數(shù)據(jù)訪問出現(xiàn)在后臺中,將不得不面對一個數(shù)據(jù)訪問的代碼重復問題,在量的相同表操作的語句出現(xiàn)在了功能相近的頁面之中.所以當客戶需求變動之后(針對單個模塊),其它模塊會出現(xiàn)連鎖問題.這就是代碼重復帶來的潛在Bug.
(2)數(shù)據(jù)表設計不符合三范式的要求.可以說完全沒有主外鍵關(guān)系.這就出現(xiàn)的一個十分有趣的現(xiàn)在當對不同表進行聯(lián)合查詢時結(jié)果不一致.據(jù)我估計可能是在開發(fā)時少有一種全局的設計,全部以頁面來決定數(shù)據(jù)庫設計所致.
(3)業(yè)務邏輯在后臺中,沒有重復的可能.對于業(yè)務邏輯的抽象我也沒有太多的理解.只是有一些理論.畢竟我也看完了<<企業(yè)級架構(gòu)模式>>的人.呵呵.
二期終于還是來了.面對一期的問題客戶也提出了相應的要求.三層開發(fā).
這還不簡單呵呵,我暗笑.三下五除二,,把架構(gòu)建起,寫了幾個簡單的Demo.就這樣負責程序架構(gòu)的事就讓我擔上了..誰知......在開發(fā)第一個實驗性的模塊時..慘痛的一幕出現(xiàn)了..事務問題..我真的沒有想到SQLServer不能外面嵌套事務問題...汗。。。。
第一次感覺到怎么多層程序開發(fā)和面向?qū)ο蟮乃枷脒@樣的不相容...
于是請教了高人...于是我們開發(fā)開會討論...提出以下方案...
(1)在業(yè)務層創(chuàng)建Transaction對象實例,,在調(diào)用DAL層時把它傳下去...我靠,,牛,,
(2)在DAL層需求事務的地方,,用一個事務把多條SQL語句包上..哈哈,,代碼重復啊,
(3)Enterprse sevices提供的COM+服務.這個強,,那時候還沒搞過.
(4)換開發(fā)工具到05,,暈了,,還在用03開發(fā),,原始新人類.(System.Transaction)
開會Ing..我提出了(2)和(3)的方案,,可是最后全被否了,理由是COM+沒搞過..(2)垃圾..暈.
最后定的方案是:
Model按表定義,并添加自定義屬性,用一個SQL生成工具類來動態(tài)的生成SQL語句..想法挺好..
也想快點見識下...
又是一個星期的....準備..
最終我終于見到..大體設計是這樣的..
(1)簡單的對單表的添加刪除修改查詢(全部)SQL語句用工具生成.,
(2)重復的查詢和業(yè)務過程用直接在表示層寫SQL語句寫,,后向下傳.(我的媽...)
(3)事務問題解決辦法:把二個Model傳入一個函數(shù)..在BLL層轉(zhuǎn)換一個DAL在DAL形成一個事務后用工具生成二條SQL語句.(很自豪..事務問題解決了).
個人意見:(不敢明說\說了也沒用)
(1)設計思想還是以表為主.這沒有錯,但用法有問題,,之所以Model用表,就是為了那讓那個工具類生成簡單的添加刪除修改查詢(簡單)SQL語句,對于復雜的查詢等,還是用SQL語句,讓人很是不解.期間一點解決復雜業(yè)務過程的意思都沒有.吐.
(2)對于復雜查詢和復雜的業(yè)務過程用SQL語句從表示層向下傳.啥也別說了..表示層在沒用也不能這樣用啊,呵呵.
當我提我們能不能把事務的處理層次提高點,放業(yè)務層上啊,沒人理,,一名話:事務還分層次.我靠,牛比.事務并不是只有Ado.net級別.并不是收集SQL語句到DAL層執(zhí)行就是解決了事務問題.我們要明白分層的目的,我們的業(yè)務怎么抽象,,我們的業(yè)務現(xiàn)在不還是混合在SQL語句中,哭死沒人管嗎?

轉(zhuǎn)載于:https://www.cnblogs.com/nanshouyong326/archive/2006/11/26/573210.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的程序架构之争的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。