從本篇開始，本系列將進(jìn)入實戰(zhàn)演練階段。

　　前面主要介紹了一些應(yīng)用程序框架的概念和基類，本來想把所有概念介紹完，再把框架內(nèi)部實現(xiàn)都講完了，再進(jìn)入實戰(zhàn)，這樣可以讓初學(xué)者基礎(chǔ)牢靠。不過我的精力很有限，文章進(jìn)度越來越慢，所以準(zhǔn)備切換一下介紹順序，把實戰(zhàn)演練提前，以方便你閱讀代碼。

實戰(zhàn)演練介紹

　　本系列實戰(zhàn)演練共分兩個部分。

　　實戰(zhàn)演練第一部分介紹如何快速解決CRUD機(jī)械操作，這一部分我將手把手帶領(lǐng)各位同學(xué)從搭建VS環(huán)境開始，創(chuàng)建程序集及各程序集間的依賴關(guān)系，以及引入依賴的外部DLL，并手工完成代碼示例中Application的三種界面操作。當(dāng)你熟悉了手工操作方式后，你會發(fā)現(xiàn)這些工作枯燥乏味，效率低下，且容易出錯。為解決該問題，我將為你介紹PowerDesigner(PD)和CodeSmith兩大工具，分享PD及數(shù)據(jù)建模技巧，并發(fā)布配套的CodeSmith模板，你將體驗到高質(zhì)量完成機(jī)械代碼的最佳實踐。

　　實戰(zhàn)演練第一部分介紹的內(nèi)容很有用，它將幫助你完成大量體力活，但這個示例太簡單，體現(xiàn)不出領(lǐng)域模型的威力，實戰(zhàn)演練第二部分以權(quán)限模塊為例，演示如何開發(fā)具有一定業(yè)務(wù)邏輯的模塊。

　　當(dāng)然，在介紹實戰(zhàn)演練第二部分之前，我需要先把框架內(nèi)部重要代碼講解完，本系列大致構(gòu)成如下：

示例代碼閱讀建議

　　很多同學(xué)反映，閱讀我的示例代碼非常困難，經(jīng)過了解，我發(fā)現(xiàn)大多是閱讀方法有問題，在此給出一些建議。

　　對于別人的代碼，你閱讀起來很痛苦是正常現(xiàn)象，因為編程習(xí)慣和風(fēng)格不同，另外一個原因是對代碼的意圖不了解。

　　我提供了Managements和Util兩個VS解決方案，Managements是簡單管理系統(tǒng)的代碼示例，Util是框架代碼，它是基礎(chǔ)設(shè)施層的一部分，被分離出來的原因是讓業(yè)務(wù)項目更簡單、編譯更快。

　　閱讀代碼需要從簡單的東西入手，這里就是Managements解決方案，它里面包含了一個叫Application的CRUD操作，它是權(quán)限系統(tǒng)中的應(yīng)用程序模塊，具體功能先不要考慮。Application模塊是一個單表操作，非常簡單，幾乎沒有業(yè)務(wù)邏輯，很適合用來入門。EasyUi提供了三種數(shù)據(jù)錄入方式，即表單操作、表格操作、行內(nèi)操作，我使用Application模塊演示了這幾種操作方式。

　　有些同學(xué)下載代碼后，直接看的Util代碼，它主要包含一些基類和公共操作類，看起來困難就在所難免了。

　　為了減少程序集數(shù)量，我把一些第三方開源框架的代碼直接放入Util解決方案中，有些同學(xué)直接就看到這里面去了，然后告訴我異常復(fù)雜。不要泄氣，說明你是一個正常人，對于第三方開源框架的代碼，我也害怕，嘿嘿。我的代碼風(fēng)格很容易辨認(rèn)，就是每個方法都具有中文注釋，當(dāng)你發(fā)現(xiàn)代碼沒有注釋或注釋全是英文，那一定不是我寫的，我的英文水平很菜。

　　當(dāng)你把Application看熟以后，可以自己動手創(chuàng)建與Application類似的表，并手工完成三種CRUD操作。

　　當(dāng)你對CRUD相關(guān)的類和配置熟悉之后，就可以查看基類實現(xiàn)，這時候帶著問題去看Util代碼，會容易理解得多。

　　下一步就是把這些代碼逐步移植到你自己的項目中，只有把它們變成你的東西，才能發(fā)揮更大作用。這也是我寫這個系列的目的，不僅授之以魚，更要授之以漁。

　　建議你至少能夠擴(kuò)展之后，才把我的東西用到你的項目上，不然坑很多，風(fēng)險高。

CRUD概述

　　CRUD是Create、Retrieve(Read)、Update、Delete的縮寫，中文名：增刪改查。不論哪家的應(yīng)用框架，都特別關(guān)照它幾兄弟，為什么？

　　對于一般的中小型項目，業(yè)務(wù)邏輯復(fù)雜的模塊只占很小的比例，一半以上的模塊都比較簡單。這些簡單模塊大致會通過一個界面或設(shè)備接口把數(shù)據(jù)收集上來，基本不經(jīng)過中間處理（業(yè)務(wù)邏輯），直接存入數(shù)據(jù)庫，在有需要的時候會把這些數(shù)據(jù)展示出來，或者為復(fù)雜模塊提供基礎(chǔ)支持。

　　這些簡單模塊工作量大，技術(shù)含量低，通過手工的方式編寫效率低下。

　　當(dāng)采用了分層架構(gòu)，特別是DDD分層架構(gòu)之后，更是雪上加霜。

　　對于采用了DDD這種復(fù)雜分層架構(gòu)，哪怕業(yè)務(wù)邏輯很復(fù)雜，還是存在不少機(jī)械工作，主要是創(chuàng)建各層的構(gòu)造類型，比如領(lǐng)域?qū)嶓w及屬性、DTO及屬性映射、EF映射等，這些工作是必須的，但很枯燥乏味。

　　可以看到，只要是信息系統(tǒng)，不論簡單還是復(fù)雜，都存在機(jī)械工作，不同性質(zhì)的項目機(jī)械工作所占比例不一樣而已。

　　后面我將用CRUD來指代開發(fā)中碰到的一切機(jī)械工作。

　　對于機(jī)械工作，最好的辦法是依靠生成器自動創(chuàng)建代碼，在討論生成器之前，先討論下EF相關(guān)的概念。

混亂的EF概念

　　EF在剛出土的時候，提供一個叫實體數(shù)據(jù)模型的edmx文件，打開這個文件，發(fā)現(xiàn)它是一個可視化類圖設(shè)計器。

　　在新建edmx文件時，有“從數(shù)據(jù)庫生成”和“空模板”兩個選項。

　　如果你選擇“從數(shù)據(jù)庫生成”，說明你自己先創(chuàng)建了數(shù)據(jù)庫，再通過edmx的反向生成工具生成代碼，這就是所謂的db first，first是先行或優(yōu)先的意思，db first就是數(shù)據(jù)庫先行，先創(chuàng)建數(shù)據(jù)庫，再讀取數(shù)據(jù)庫的元數(shù)據(jù)，生成代碼。

　　如果你選擇了“空模板”，你可以在edmx可視化類圖設(shè)計器中創(chuàng)建一些類和關(guān)聯(lián)，edmx會自動幫你生成代碼和數(shù)據(jù)庫。這種方式稱為model first，即模型先行，先有模型，后面再創(chuàng)建代碼和數(shù)據(jù)庫。

　　代碼生成出來后，你會發(fā)現(xiàn)這些代碼文件被包含在edmx文件中，包括領(lǐng)域?qū)嶓w和DbContext工作單元，還有一些T4模板，這有什么影響？

　　如果采用DDD分層架構(gòu)，領(lǐng)域?qū)嶓w屬于領(lǐng)域?qū)?#xff0c;而DbContext屬于基礎(chǔ)設(shè)施層，放到一起會導(dǎo)致高耦合以及分層不清，這是edmx的主要問題。另外一堆不相干的代碼生成模板與領(lǐng)域?qū)嶓w放到一起，估計也讓你看著心煩。

　　EF后續(xù)推出了更加輕量的使用方式，讓你可以拋棄edmx文件，直接使用原生的DbContext，并支持了code first開發(fā)模式。code first即代碼先行，先寫代碼，再自動創(chuàng)建數(shù)據(jù)庫。code first開發(fā)模式能夠真正實現(xiàn)持久化無關(guān)，從而設(shè)計出更加純凈的領(lǐng)域模型，特別在采用TDD開發(fā)時，更加威猛。

　　從上面可以看出，edmx和原生DbContext是兩種不同的EF技術(shù)，而db first、model first、code first則是不同的開發(fā)模式，但這些術(shù)語非常混亂，不同的人說同一個術(shù)語時可能指的是不同的東西。

　　經(jīng)常聽到有人說他用的是code first，但實際上他的開發(fā)方式是先創(chuàng)建數(shù)據(jù)庫，再生成代碼，這屬于db first，他用code first指代原生DbContext技術(shù)。

　　還有一些人害怕使用EF，因為他認(rèn)為原生DbContext只能使用code first開發(fā)模式，而他想采用db first方式，但他又不喜歡edmx。

　　我用原生DbContext這個詞的意思是，單獨使用DbContext這個基類，因為edmx也使用的是DbContext，以示區(qū)別。

　　下面用一個圖來總結(jié)一下，如果說得不正確，請各位同學(xué)批評指正。

Code First還是Db First

　　從上面分析得知，edmx不適合DDD分層架構(gòu)，所以我們在EF技術(shù)上采用原生的DbContext，這個沒有什么疑問了。那么開發(fā)模式是否一定要采用code first呢？

　　前面說了，code first可以獲得更純的領(lǐng)域模型，但你見過爐火純青的領(lǐng)域模型長什么樣嗎？對于DDD架構(gòu)初學(xué)者，在很長時間都難領(lǐng)悟到它的精髓，所以不論你以code first還是db first，其結(jié)果沒有顯著不同。

　　其次，.net大部分項目都是中小項目，且不太復(fù)雜，CRUD機(jī)械工作占很大篇幅，使用code first手工敲代碼，效率十分低下，且工作量與表中的字段數(shù)量成正比。在配合TDD的情況下，才可以和生成的代碼質(zhì)量媲美，否則BUG依舊。

　　可以看到，雖然code first萬眾矚目，但卻只有DDD高手開發(fā)很復(fù)雜的業(yè)務(wù)才能真正發(fā)揮威力。很復(fù)雜的業(yè)務(wù)需求，可能邏輯非常復(fù)雜，僅簡單搜集數(shù)據(jù)字段，并不能很好的完成任務(wù)，這種場景基于DDD進(jìn)行行為建模并配合TDD推進(jìn)項目更有保障。

　　根據(jù)我的項目實際情況，我采用了db first，第一步用PD數(shù)據(jù)建模，第二步用PD生成建庫腳本創(chuàng)建數(shù)據(jù)庫，第三步采用CodeSmith生成代碼，第四步選擇性的復(fù)制代碼并建立領(lǐng)域模型。

代碼生成器介紹

　　很多同學(xué)一聽代碼生成器，就會問哪種生成器最好，還有些同學(xué)則干脆自己開發(fā)，畢竟大家都是程序員，要開發(fā)個生成器軟件有何難。

　　技術(shù)人員總是對技術(shù)本身比較感興趣，容易忽略做一件事的真正目的。其實對于代碼生成器來說，真正重要的不是生成器軟件，而是你需要獲得的最終代碼，它是由你的模板決定的。

　　要創(chuàng)建出一套高質(zhì)量的模板，關(guān)鍵是不斷提純自己的代碼，把重復(fù)的代碼盡量提取到基類。

　　對于采用哪種生成器軟件，根據(jù)自己的熟悉程度和喜好進(jìn)行選擇，我采用的是CodeSmith。

　　CodeSmith是一個收費的代碼生成器，不過大家都使用綠色環(huán)保版本。使用它的原因是功能比較強(qiáng)大，能夠與VS進(jìn)行集成，編寫模板時具有代碼提示，類似ASPX語法，學(xué)習(xí)成本低，另外官方提供了一套EF DbContext模板，我們只需要簡單修改，就可以用于實際開發(fā)中。

　　需要創(chuàng)建哪些部分的代碼呢？在最理想的情況下，所有機(jī)械代碼全部生成，這樣你可以在最短時間內(nèi)拿下大部分機(jī)械工作，為你能夠集中火力完成核心功能奠定基礎(chǔ)。

　　下面討論幾個與生成器相關(guān)的問題。

代碼生成器與數(shù)據(jù)建模的關(guān)系

　　一般的代碼生成器都是通過讀取數(shù)據(jù)庫元數(shù)據(jù)來生成代碼。

　　如何評價生成的代碼質(zhì)量高低？

　　第一個特征，所有代碼是否具有準(zhǔn)確的注釋。

　　大部分程序員都不喜歡寫注釋，不知道是因為打字慢，還是覺得沒必要。哪怕你英文很牛X，你的命名非常標(biāo)準(zhǔn)，但你不能保證看你代碼的人具有同樣的英文水平。何況大部分人的英文還是和我一樣菜，命名十分晦澀。在這種情況下，不要說給別人留條活路，那是給自己將來留的。

　　如果你采用code first模式，手工編寫所有代碼，相信能給全套代碼寫全注釋的人不多，每個領(lǐng)域?qū)嶓w的屬性頭上都要加上注釋，而且還有大量相似類，比如Dto，不復(fù)制代碼很難做到。

　　第二個特征是自動幫你生成EF導(dǎo)航屬性及相關(guān)映射配置，這是通過讀取外鍵關(guān)系來創(chuàng)建的。

　　很多.Net程序員不知道數(shù)據(jù)建模的價值，如果你問我一個項目里，哪種文檔最重要，我會毫不猶豫的告訴你——數(shù)據(jù)建模文檔。

　　為什么數(shù)據(jù)建模這么重要，如果你現(xiàn)在接手一個遺留系統(tǒng)，你最需要什么？需求文檔？類圖？序列圖？需求你不懂，還可以找用戶問，但數(shù)據(jù)庫中一個命名很晦澀的列，你要猜出它是什么意思，則難如登天。而類圖和序列圖等UML建模，主要是前期幫助理解和設(shè)計領(lǐng)域模型，不一定能夠與代碼同步更新，另外也不可能對每一個模塊創(chuàng)建UML，完全沒有必要。

　　通過PowerDesigner進(jìn)行數(shù)據(jù)建模，你可以讓系統(tǒng)清晰度上升幾個層次，讓你看清表之間的關(guān)系，以及每個列的具體含義。

　　你可以在數(shù)據(jù)建模時，把每個列的注釋加上，用PD創(chuàng)建數(shù)據(jù)庫后，生成的代碼中就具有良好的注釋了。

　　當(dāng)你在表之間用關(guān)聯(lián)線一拖，外鍵關(guān)系就建立了，生成的代碼就具有了導(dǎo)航屬性。

　　當(dāng)然你可以直接在數(shù)據(jù)庫中創(chuàng)建表，并添加注釋，并手工創(chuàng)建外鍵關(guān)系。但這并沒有讓你減輕工作量，反而工作量更大，使用數(shù)據(jù)建模，工作輕松高效，且對項目未來維護(hù)有深遠(yuǎn)影響。

　　生成高質(zhì)量代碼，除了你的模板外，另一個影響它的就是數(shù)據(jù)建模。

　　我將在后面幾篇分享我整理的CodeSmith模板，對于簡單的CRUD操作，它可以生成全套代碼，代碼質(zhì)量與我手工編寫無異。

是否批量生成代碼

　　對于從三層架構(gòu)過來的朋友，很多都用過代碼生成器。

　　如果系統(tǒng)有100個表，他們會把這100個表先建好，然后一次生成出來，然后再花幾小時到幾天的時間來整理修改。

　　這個開發(fā)效率看上去很誘人，對于比較簡單的三層架構(gòu)和SQL操作可能是有效的，但對于EF+DDD分層架構(gòu)卻不太吃香。

　　對于EF的導(dǎo)航屬性，生成出來都是雙向?qū)Ш?/strong>，但為了降低復(fù)雜度，可能會手工調(diào)整為單向?qū)Ш?/strong>，這時候也需要手工修改映射代碼。