前面我有一篇隨筆重復(fù),為什么我們要不斷重復(fù)講述的是我在項(xiàng)目開發(fā)中的苦惱,引發(fā)了很多人討論,大家各出高招,有人提到ORM,按我的愚見,ORM是在應(yīng)用程序的類和數(shù)據(jù)庫中表及視圖建立一對一關(guān)系,例如,數(shù)據(jù)庫中有表tblarticle,那么與之對應(yīng),我們可以建立一個(gè)articleItem對象來表示單條的記錄,表的每個(gè)字段做為articleItem的成員變量,對應(yīng)表的insert,update,delete以及select item及select all等存儲過程,我們可以為articleitem建立對應(yīng)的方法,然后在方法中用ADO.NET及對應(yīng)的存儲過程來完成數(shù)據(jù)的抽取,修改等.并且,我們可以在articleitem的基礎(chǔ)上建立articleitemcollection以表示多條記錄,這樣,就將單條記錄的更新變成了建立一個(gè)articleitem對象,給article對象的各種屬性賦值,最后調(diào)用像articleitem,update()這樣的方法來完成數(shù)據(jù)操縱的目的.這種實(shí)現(xiàn)方式其實(shí)很容易令人接受,并且,如果A負(fù)責(zé)寫數(shù)據(jù)存取層的話,B用的時(shí)候,幾乎不用關(guān)心是在操縱哪個(gè)表,而只關(guān)心操縱的是何種對象.非常類似我們使用.NET類庫中對象一樣.
可是,聽起來不錯(cuò),但如果真的要你去用ORM做一個(gè)項(xiàng)目的時(shí)候,你會(huì)發(fā)現(xiàn)代碼量遠(yuǎn)遠(yuǎn)大于使用"傳統(tǒng)"的直接用ADO.NET調(diào)用存儲過程的方法.雖然使用ORM可以讓我們項(xiàng)目在以后的維護(hù)中更加容易,可是,在項(xiàng)目的初期,真的會(huì)拖慢開發(fā)速度,所以,很多博客堂的朋友覺得,與其ORM,不如就用ADO.NET來
可是,ADO.NET直接操作首先帶來的問題是,你的項(xiàng)目只能模向分隔(比如,你可以把為一個(gè)數(shù)據(jù)庫中某幾個(gè)表寫數(shù)據(jù)存取層的任務(wù)交給A,另外的交給B),無法進(jìn)行縱向?qū)哟蔚姆指?如果用ORM,你可以讓A負(fù)責(zé)寫數(shù)據(jù)存取層,讓B寫對象層,讓C寫業(yè)務(wù)邏輯層,協(xié)作上容易的多.
既然傳統(tǒng)方法和ORM都不是那么完美.那有沒有更好的方法呢?雖然我也聽說過"銀彈"故事.我也相信世界上沒有銀彈.但是我仍然孜孜不倦的追求完美,仍然想找到合適的解決方案.
CodeSmith這個(gè)軟件在博客堂和CSDN不知道有多少人提過了.大多數(shù)的解釋是CODeSmith是一個(gè)快速代碼生成工具.試用后,CodeSmith給我了強(qiáng)烈的震撼,假如它只是一個(gè)基于模板的代碼生成工具.那么我不認(rèn)為有什么了不起.可是它竟然克服了模板生成工具的靈活性不足缺陷.它在高效率和高定制性間取得了完美的平衡.如果你沒有用過他,我可以告訴你他有以下特點(diǎn):
1.他可以用于生成C#,VB.NET,TSQL以及其他任何語言代碼
2.他本身是可以編程的(這是他的靈活性之源)
3.他提供了強(qiáng)大的SchemaExplorer對象,使數(shù)據(jù)庫儲過程的生成非常容易
4.有了他,你不會(huì)再向我一樣埋怨從一個(gè)項(xiàng)目到另一個(gè)項(xiàng)目時(shí),需要重新寫許多代碼.因?yàn)槟阒恍枰惶啄０宥?
5.他使用的語法是典型的ASP.NET語法,并且,可以像我們寫ASP那樣將代碼和靜態(tài)內(nèi)容混和撰寫(好像在寫ASP的時(shí)代一樣)
舉一個(gè)簡單的例子,你就可以明白他的強(qiáng)大
下面是我根據(jù)Quick Start Guide寫的一個(gè)模板,作用是生成一個(gè)簡單的類框架,不要小看他呀
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=424569
