国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

　　為期三個(gè)月的開發(fā)加測(cè)試工作終于告一段落了，這是我們團(tuán)隊(duì)第一次采用ASP.NET MVC（直接使用最新的MVC 3）開發(fā)企業(yè)應(yīng)用，期間碰到了很多問題，但在大家的努力下，也都一一解決，先簡(jiǎn)單介紹一下項(xiàng)目情況吧，是公司的一套業(yè)務(wù)運(yùn)營(yíng)系統(tǒng)，總的從技術(shù)實(shí)現(xiàn)難度來講，沒有什么特殊的地方，只有相關(guān)部分的業(yè)務(wù)邏輯算法比較復(fù)雜。項(xiàng)目開始前，最大的風(fēng)險(xiǎn)在于整個(gè)team除了另外一名同事和我使用過MVC，其他人都是第一次使用，并且另外那名同事在項(xiàng)目開始一個(gè)月左右離職了~~!好在通過大量的交流溝通、code review、內(nèi)測(cè)等手段下，項(xiàng)目基本成功完成。

一、技術(shù)架構(gòu)介紹

　　基于.Net的多層解決方案，web框架采用了微軟的ASP.NET MVC 3（視圖引擎為Razor），數(shù)據(jù)層采用Entity Framework 4.0。界面組件方面使用了Telerik for MVC版本，JS框架依然是強(qiáng)大的JQuery。 系統(tǒng)提供了中、英兩套語(yǔ)言版本，采用微軟官方推薦的多語(yǔ)言解決方案，該方案很容易擴(kuò)展其他語(yǔ)言版本。

二、MVC

　　個(gè)人感覺ASP.NET MVC 3相比2和1，并沒有帶來革命性的變化，但一些小的改進(jìn)還是相當(dāng)不錯(cuò)的，也提高了不少開發(fā)人員的效率。
以下列表顯示了我們用到的一些ASP.NET MVC的特性（包括ASP.NET MVC 3但不限于3）
1. 基于layout的頁(yè)面結(jié)構(gòu)，一個(gè)首頁(yè)可以拆分成如下： 包含title、head、body、以及公用JS、CSS文件的最頂層layout。 包含菜單導(dǎo)航的分部視圖（Partial View） 包含主頁(yè)面內(nèi)容的View。 主頁(yè)面里又可以包含其他公共的分部視圖，或?yàn)榱藢哟胃逦藶椴鸱值倪壿嫴糠忠晥D（設(shè)計(jì)合理的部分視圖有利于提高代碼層次的清晰程度，但過多的使用也會(huì)降低系統(tǒng)性能，畢竟多了一些IO操作）。
2. 通過使用ViewResult、ActionResult、PartialResult、JsonResult輸出不同的內(nèi)容。
3. 新增了Dynamic特性，配合Razor可以很方便的在視圖上使用控制器提供的數(shù)據(jù)。
4. MVC Chart組件可以很方便的輸出比較專業(yè)的圖表。
5. 控制器基類提供了很多重寫方法，可以較為方便的進(jìn)行一些全局的處理，例如：異常、方法級(jí)別的注入等。
6. unobtrusive js，通過服務(wù)器端ModelMetadata和客戶端的unobtrusive js，可以做到前后臺(tái)的統(tǒng)一驗(yàn)證，大大減少開發(fā)量。

三、Razor

　　采用了微軟最新的Razor（模板引擎語(yǔ)言）配合MVC3進(jìn)行開發(fā)，新一代的視圖引擎Razor以簡(jiǎn)潔的“@”開頭的寫法，對(duì)強(qiáng)類型的智能感知做的也非常不錯(cuò)（不過在JavaScript代碼部分的智能感知還是有些問題）。 相比ASPX視圖引擎，Razor還是勝在簡(jiǎn)潔上，也有第三方的NVelocity模板引擎，雖然語(yǔ)法也很簡(jiǎn)潔，但智能感知方面就做的比較差了，因此，開發(fā)ASP.NET MVC 3，Razor還是首選。 至于性能上的比較，沒有實(shí)際分析過，可能會(huì)比ASPX略遜一些。
總結(jié)Razor的優(yōu)點(diǎn)如下：
1. 代碼流暢簡(jiǎn)潔。
2. 與HTML結(jié)合很順暢，不需要單獨(dú)處理大括號(hào)。
3. 代碼高亮顯示。
4. 很方便的輸出單行文本（@:）或多行文本（）。

四、Entity Framework

　　數(shù)據(jù)層采用微軟提供的ORM框架Entity Framework，并配合Linq To Entity，能夠以簡(jiǎn)潔的linq語(yǔ)句或lambda表達(dá)式，來代替復(fù)雜冗長(zhǎng)的SQL語(yǔ)句。 總體上來講EF相比Linq To SQL，并沒有特別大的不同，其中結(jié)合Validation類來對(duì)Model進(jìn)行MetadataType的標(biāo)記，來實(shí)現(xiàn)數(shù)據(jù)的校驗(yàn)，感覺是一個(gè)比較不錯(cuò)的方式。更能體現(xiàn)代碼單一職責(zé)原則，我們不必要在控制器里寫大量的校驗(yàn)邏輯。
　　EF的edmx文件在從數(shù)據(jù)庫(kù)更新的時(shí)候，容易出現(xiàn)更新不成功的情況，這時(shí)候則需要將實(shí)體刪除并從數(shù)據(jù)庫(kù)新增就可以解決這個(gè)問題。 對(duì)于EF的DBContext，在不同層傳遞的時(shí)候，應(yīng)該盡量一致，個(gè)人更傾向于實(shí)例化對(duì)象的方式，而且比較好的實(shí)踐方式是： 在業(yè)務(wù)層持有一個(gè)全局的數(shù)據(jù)層對(duì)象引用，在控制器里使用實(shí)例化的業(yè)務(wù)層對(duì)象對(duì)數(shù)據(jù)庫(kù)進(jìn)行讀寫操作。 在項(xiàng)目的前期，因?yàn)榇罅渴褂昧藬?shù)據(jù)層或業(yè)務(wù)層的靜態(tài)方法，以至于在業(yè)務(wù)邏輯相對(duì)簡(jiǎn)單的系統(tǒng)管理模塊出現(xiàn)了大量的bug，主要的原因就是數(shù)據(jù)上下文使用混亂，前后不一致，應(yīng)該說是我們的一個(gè)教訓(xùn)。 需要謹(jǐn)慎處理延遲加載，以降低性能方面的影響。什么時(shí)候需要延遲加載、什么時(shí)候不需要延遲加載，感覺還是跟具體的業(yè)務(wù)邏輯有關(guān)，不能一概而論。 數(shù)據(jù)對(duì)象的使用也是要考慮的一方面，尤其是在前臺(tái)更改了某些數(shù)據(jù)屬性之后，在同一個(gè)上下文里進(jìn)行數(shù)據(jù)保存操作后，可能會(huì)出現(xiàn)你所不期望的修改。尤其是在復(fù)雜的業(yè)務(wù)計(jì)算類庫(kù)上面，一個(gè)對(duì)象經(jīng)過重重傳遞，很容易出這個(gè)問題，并且不太好查。

總結(jié)：要明確的知道數(shù)據(jù)對(duì)象的使用范圍。

五、AOP

　　對(duì)于ASP.NET MVC 3來講，天生就是支持AOP的，框架自帶的ActionFilterAttribute基類提供了四個(gè)重載方法，
如下所示：
1. public virtual void OnActionExecuted(ActionExecutedContext filterContext)該方法在Action執(zhí)行之后觸發(fā)。
2. public virtual void OnActionExecuting(ActionExecutingContext filterContext)該方法在Action執(zhí)行之前觸發(fā)。
3. public virtual void OnResultExecuted(ResultExecutedContext filterContext)該方法在Result渲染完之后觸發(fā)。
4. public virtual void OnResultExecuting(ResultExecutingContext filterContext)該方法在Result渲染之前觸發(fā)。

通過這四個(gè)重載方法，可以非常方便的將代碼邏輯織入到Action的生命周期內(nèi)。 對(duì)于我們這個(gè)系統(tǒng)，實(shí)現(xiàn)了如下幾個(gè)方面的織入：
1. 功能權(quán)限控制。
2. 數(shù)據(jù)權(quán)限控制。
3. 項(xiàng)目狀態(tài)檢查。
4. 操作日志。

AOP帶來的好處也是顯而易見的，減少代碼量、降低業(yè)務(wù)邏輯和非業(yè)務(wù)邏輯代碼的耦合度、便于維護(hù)。

六、Telerik

　　為了提高開發(fā)效率和復(fù)用代碼，在界面上也大量的使用了Telerik控件for ASP.NET MVC版本。
主要有如下應(yīng)用：
DatePicker，日期選擇組件，其中可以設(shè)置可以選取的范圍是亮點(diǎn)，但其本身綁定的一些事件也是有利有弊（例如Onblur之后的自動(dòng)設(shè)置日期值），客戶端不能靈活的控制。
Window，仿模態(tài)窗口，彈窗利器。
Grid，表格組件，功能很強(qiáng)大，但有些特殊場(chǎng)景還是很別扭。同樣是客戶端控制程度不夠。
TreeView，樹組件，功能也很強(qiáng)大，很好用。

總結(jié)：有一套好的可復(fù)用組件確實(shí)能大大提高開發(fā)效率，但前提是要對(duì)其有較好的把控能力，否則容易適得其反。

七、多語(yǔ)言解決方案

　　采用微軟官方推薦的資源文件做法，我們這個(gè)系統(tǒng)有中、英文兩個(gè)版本，則在所有的顯示字段、交互提示等地方，全部使用了資源文件標(biāo)簽。 其原理就是根據(jù)用戶選擇的語(yǔ)言種類（存到cookie），動(dòng)態(tài)設(shè)置當(dāng)前線程的語(yǔ)言環(huán)境，剩下的事情微軟已經(jīng)幫我們做好了，實(shí)現(xiàn)起來很簡(jiǎn)單，推薦使用。

關(guān)鍵代碼：

八、其他：log4net、NPOI

　　同時(shí)也采用了一些其他優(yōu)秀的開源框架： 使用log4net來記錄異常日志和一些操作日志，使用npoi來進(jìn)行excel操作。這兩個(gè)框架都是從JAVA平臺(tái)移植過來，不得不說，JAVA社區(qū)在開源框架方面的研究要?jiǎng)儆?Net。

九、未來考慮

　　引入Ioc框架：為了降低業(yè)務(wù)層與數(shù)據(jù)層、控制器之間的耦合，使代碼更靈活以及更容易擴(kuò)展和維護(hù)，考慮后續(xù)引入IOC框架（例如：unity、spring.net、castle windsor等）
　　采用獨(dú)立緩存服務(wù)器：一直以來，緩存都是提升系統(tǒng)性能最廉價(jià)的解決方案，目前我們需要緩存的數(shù)據(jù)量較小，直接使用.Net自帶緩存進(jìn)行緩存處理，例如：組織機(jī)構(gòu)、功能菜單等，雖然.NET自帶的緩存功能很強(qiáng)大，但畢竟和app server共用內(nèi)存，且處于同一應(yīng)用程序域內(nèi)，如果在緩存使用較多的情況下，性能不是很理想。未來考慮使用分布式緩存，例如：memcache、redis等優(yōu)秀的第三方緩存框架。
　　更好的用戶體驗(yàn)，主要體現(xiàn)在優(yōu)化部分操作流程和頁(yè)面操作體驗(yàn)。
　　WCF重構(gòu)部分服務(wù)以支撐更多不同類型的客戶端。