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

轉載于:https://www.cnblogs.com/nanshouyong326/archive/2006/11/26/573210.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。