我是一名.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 業務對象支持
這是基礎模塊了，實現了業務對象的無SQL CRUD操作。
四、圖表模塊
可以實現各種圖表的顯示，柱狀圖，餅圖之類的，如果你用過DEV的控件，你就已經看過它的效果圖了。
五、Clone Objct模塊
實現了業務對象的復制，這是一個小模塊。
六、Conditional Appearance Module Overview
條件外觀模塊，非常常用的模塊，實現全局的控制控件是否可用，可見，顏色、
字體等 。
七、FileAttachment Module,文件附件模塊
用于管理附件文件，可以傳到數據庫中，也可以個性化為文件系統。
八、HTML Property Editor
在業務對象中可以使用html編輯器。
九、Notifications Module
提醒模塊，像
Outlook一樣，到達某時間給出一個彈出提醒，可以選擇推遲或取消，可以在業務模塊中進行個性化。
比如，到時間提醒去聯系客戶，更新訂單等操作。
十、KPI模塊
績效考核模塊，工作的朋友應該都被考核過吧，是標準的模塊，可以提供一些圖表。
十一、Maps模塊
支持地圖的顯示，這個我還沒有用過，不過看起來還不錯。
十二、Pivot Chart Module
交叉數據分析表+圖表模塊，在Excel中有交叉數據透視分析表，因為樣子長得一樣，我就這么翻譯了。
這個確實相當強大，客戶可操控性很強，要什么數據統計結果，隨心所欲，當然，客戶要愿意操作。
這個模塊同時帶了圖表顯示，可以將Pivot中的數據同時顯示成圖表，很直觀。
十三、Pivot Grid Module
和上面的一樣，只有Pivot表格的顯示。
十四、報表模塊
當前版本是15.2了，新的功能不斷在增加，以前的版本中我們一直在等很多很好的功能。比如報表模塊，以前只能在win中做報表設計，現在web中也有了報表設計器了。
相當高大上。
十五、Scheduler 模塊
和Outlook中的日歷一樣。
十六、狀態機模塊
做簡單審批流用的，還不錯。
十七、TreeListEditor
樹形列表模塊，這個也很常用。
十八、驗證模塊
這個使用頻率是最高的，必填驗證，唯一驗證等 ，你能想到的都有了。當然也提代了擴展接口。
十九、View Variant
讓一個業務對象有多種是顯示方式，并可以快速切換。比如圖表界面切換成樹形視圖。
二十、工作流模塊
就是工作流了，當前只在winform下可用。
九、缺點
1.需要學習
2.體系龐大
好吧，今天就介紹這么多吧，我也只能想到這么多了！另外，本文發表時，我已經寫了6篇入門教程，如果需要請來我的blog中查看。
另外，就算你不打算用XAF也沒有關系，我們在自己設計系統時，多多借鑒別人的好思路，是很重要的。
XAF也不是完美的，永遠沒有完美的工具，對的時候選擇對的工具吧！
說了這多，上幾張圖片，看看到底開發的系統長什么樣吧！
真的希望能幫到你！
