我是一名.Net開發者,從DOS時代Turbo c 算起(1996年),馬上滿20年了。想想寫過的代碼真是不少,卻做了很多重復反復的編碼工作。當然中間也帶過團隊做過幾個大項目,但是代碼仍沒寫夠,還是每天在敲著代碼,真心是喜歡這個別人眼中這件無聊的事情吧。
可能我的視野不夠開闊,自從2002年從asp開始加入M$陣營,後來轉向.net開發一直沒有變化過,而且一直在做企業信息系統開發,做這行的,大家都知道是工作繁重修改反復。
不管是需求變化,還是老板有新點子,我們就得加班加點,理由總不需要那麼多,只有一個就能讓你忙活個沒完沒了。
是的,一直在這種趕項目進度的時間裡,逼著我要想到底如何才能更快,更好的完成任務。我希望一個需求來了簡簡單的就能完成。然後再和老板聊薪水的時候讓他沒什麼理由說你還需要提高。當然,這也是挺可笑的,這是後話了。
我們還是說說信息系統開發效率這件事吧,在我的印象中,傳統的開發方式是這樣的:
分析需求->建立數據庫->畫界面->調用Ado.Net->調用SQL語句(或都再寫點存儲過程)
其中畫界面,不管是webform還是mvc都是跑不了的。
做了N個大小項目後,每一步都讓我惡心得想吐,以客戶信息維護為例:
建表:客戶(姓名,生日,地址,電話,聯系人)
畫界面:上面的字段挨個拖一遍。
寫SQL:增刪改查,還是圍著數據庫表來一遍。
當然還要處理什麼注入攻擊之類的。如果你正好使用了某套數據庫類庫,這裡可能會讓人省點心。
一個信息系統中多數都是這樣的操作,沒完沒了的CRUD,終於,開始流行代碼生成了,我也站在風口浪尖上,偶遇了Raptier.
CodeProject上還有介紹它的文章,難得。開發效率果然提升了,當時公司要做網站後台,我在Raptier中設置一下,一個簡單的後台就生成了。
那年我剛來上海,連續三個月,每個月和老板提一次漲工資的事情,每次都答應了。後來想想應該是起薪就要得太低了^_^
之後一段時內CodeSmith應該流行起來了,當然,代碼生成的問題很多,比如生成之後要修改,可以直接改代碼,再去改庫結構,又要重新生成。結果以前修改過的代碼就被覆蓋了。當時c#還沒有partial關鍵字。所以不管怎麼弄都挺難受的。
因為代碼生成有種種的問題,我決定自己開發框架,現在想想也是非常可笑的事情,是想做信息系統的通用型框架,可以說是沒有需求,也可以說是需求無限大。這可是大忌諱。做著做著感覺這輩子可能也做不完,從數據庫訪問到界面,再到功能模塊,什麼工作流狀態機,單據編號,數據導入,報表打印,簡直沒救了。
做到控件時我想還是去找找現成的吧,這一找不要緊,直接導致了框架的開發失敗,因為我找到了我想象中的框架,所以就棄了開發^_^
我發現了XAF!大約是在2009年,當時版本是8.X版本。
我開始學習XAF,學習得很順利,感覺這就是為我開發的,也經常對著屏幕傻笑,說:怎麼和我想的一樣呢?
當然其實我沒有那麼高明,只是發自內心的高興加點自戀!
ORM來了,不過我沒有趕上這波,直接跳格了,因為XAF中使用了XPO ORM所以才接觸到它,當時的Entity Framework簡直就是慘不忍睹。用EF朋友不要拍我,確實不咋地,但LINQ為了幫助EF確實還是很好的東東。補充一句現在EF感覺也不怎麼樣,XPO都停止開發了。為什麼EF不怎麼樣?他要是支持接口類型做為實體映射就好了,支持不同的數據庫也很周折。
現在我一直用XAF,看到很多碼農還在苦痛掙扎,我來分享一下使用經驗,讓更多的碼農解脫吧,解脫一部分也好!騰點時間出來,陪家人,陪孩子,或因開發效率提高,軟件質量提高,多拿一點點獎金,過個愉快的聖誕節吧!
當然,如果你要是認為我是XAF的推銷員,並且戴著有色眼睛看商業軟件,那請自便吧,visual studio也是商業的,所以才如此的出色!不過話說回來DEV公司確實該給我這個死忠點辛苦費!
XAF優點
一、一次編碼,多種平台同時使用
通過一次代碼編碼寫,可以同時產生四種項目:
1,Web項目(b/s)
2,win項目(c/s)
3,平板電腦(beta)
4,移動端(beta)
其中web/win是兩個項目,3,4都是web項目,只是使用了不同的適應界面可以在移動設備和平板電腦上進行浏覽操作等。
在Sliverlight剛出現的一段時間內,XAF曾試圖支持Silverlight版本,不過由於HTML5的興起,微軟至今應該把Sliverlight放到角落裡了,所以也導致了Dev公司不支持Sliverlight了。不過他們有些Sliverlight的控件。
WPF也算是不死不活的狀態,至少我看到的應用很少。VS除外,那是MS自己的東西:D
sliverlight如果沒有HTML5的出現,是個不錯的東西,太可惜了,HTML5的興起,又將我們拉回該死的javascript開發中來了。
二、數據庫支持
這應該是XPO的優點,支持14種數據庫,SqlServer,Oracle,MySql,DB2.....常見的庫都支持了。切換數據庫時,無需修改源碼,當然如果你開始用了Oracle並且手工調用了SQL語句,在sqlserver中肯定是不能正確執行的。
支持Entity Framework,雖然我不用這個,但是DEV還是支持了,可能是因為M$太強的原因吧。
三、國際化本地化支持
XAF支持多國語言版本,應用程序開發完成後,可以在應用程序模型中生成各種語言的本地化翻譯文件,這也算是高大上的支持了吧。
四、自動機制
•由領域對象開始 •自動建立數據庫 •自動建立界面 ▫列表界面 ▫詳細界面 ▫搜索界面 •內置增刪改查,無需SQL編程 五、AOP應用 AOP是面向方面的應用,XAF中被應用到了極致,比如,系統內置的 保存按鈕,無論你有多少個業務對象,只要這一個保存按鈕,它們的行為是一致的,都是保存到數據庫的表中去,如果你需要修改保存按鈕的文字,只要在一個地方修改,整個系統中都變了。 模塊化應用: 假如我們開發一個Excel數據導入功能,同樣,我們可以應用於所有業務對象中去,做一次導入功能,所有地方立即使用。XAF內置了非常豐富的元數據,我們可以使來用。 控件的復用: 系統中有很多地方需要用到一個控件,比如時間選擇,XAF默認沒有這些控件時,我們可以開發出來,並可以設置為默認控件,例如應用到Timespan類型上去,只需一步,整個系統都會應用此控件。 XAF中有許多這樣的自動機制,能一次解決的,堅決不用做兩次,拒決重復,拒決復制。 六、元數據管理 元數據是指我們的程序中代碼自身的信息,比如類叫什麼名字,它繼承自哪個類,實現了哪些接口,有哪些Attribute,有哪些屬性? 是在,在.net中,用反射可以取得到這些信息。在信息系統開發中,這個元數據會得到擴展,比如這個類將會在界面上顯示的文字是什麼,填寫數據時有哪些要求,過濾條件是什麼等等 。 你會說,這不就是我們自己寫的代碼嗎? 在XAF中這些信息也是需要維護的,我們在給客戶寫程序時是在幫助客戶管理他們的信息。他們是信息化水平提高了。但我們自己的代碼,自己的系統本身也是一個信息量龐大的需要管理的內容。我們如果不是處處考慮規劃程序本身的內容,那後面亂做一團也是很正常的事情了。 看面向對象的軟件設計中,不正是使用了各種概念對這些內容進行了規劃嗎? 於是有了一個名詞叫元編程,也是讓人著迷的東西。 那麼元數據管理有什麼用呢?它還是和AOP概念結合使用方顯功效的。 比如:我想讓所有擁有“名稱”屬性的類型,都在界面顯示為紅色,我們可以使用編程方式foreach(var x in classes) { if(x.members.contains('名稱')){ var member = x.members["名稱"]; member.backColor = Color.Red; } }
這只是一段偽代碼,如果用傳統的開發方式,每個界面這樣操作一次,可能會產生很多錯誤吧,最大的問題是,我們需要那麼笨的處理日常問題嗎? 我們為什麼沒有簡單方法,節省出時間,不做那種無聊的修改呢? 另外,元數據也是可以擴展的,內置的沒有提供的,我們可以自己實現。 七、DomainComponents技術 通常被XAF開發人員簡稱為DC技術,DC技術是使用接口定義業務邏輯對象的,在EF中,我們通常是用class來定義一個業務對象,使用接口來定義業務邏輯會更快更簡捷,我認為最大的一個好處是實現了多繼承,如:
public interface 客戶{ ...... } public interface 公司{ } public interface 個人{ } public interface 公司客戶:公司,客戶 { } public interface 個人客戶:個人,客戶 { }
這樣是多麼簡單,如果使用class,只支持單繼承,另一個接口中的內容,只能手工再次重復敲出代碼,那是多麼無聊的事情。 有一點小小遺憾的是,DC技術還不支持泛型機制,如果以後能夠支持,那它是完美的。在一個進銷存系統中,單據無比多,但無非是出庫類,入庫類,不出不入庫類,這三種,然後就有了各種可以想出來的組合,組合出了N多張單據,我們若是使用了DC技術,天空瞬間晴朗了。 八、內置功能模塊 一、權限模塊: 1.支持業務對象級別的權限,增刪改查看權限。 2.支持字段級權限,某個字段可讀可寫。 3.支持行級權限,某個業務對象中某些條件的記錄是否有權限進行 刪 、改、查看 4.支持上述4種混合權限 5.支持角色,並支持角色嵌套,即,角色3=角色2+角色1 二、審記模塊 用於實現業務對象的變更的每個環境,創建時間、修改時間、刪除時間,修改內容,每個屬性從什麼值變更為什麼值,何人操作的。 生成的記錄相當多,不過可以選擇性記錄,或自定義。 三、 Business Class Library Customization Module 業務對象支持