系列目錄

  Unity 在MVC上的應用(上:思路整理)

  Unity 在MVC上的應用(中:Repository)

  Unity 在MVC上的應用(下:ORM)

  Unity 在MVC上的應用(擴展篇:JQuery AJAX)

  Unity 在MVC上的應用(擴展篇:事務控制-前篇ActionFilter)

  Unity 在MVC上的應用(擴展篇:事務控制-后篇Unit Of Work)

  Unity 在MVC上的應用(擴展篇:日志管理NLog)

技術點應用

   1.ASP.NET MVC3 (新東西絕對要用用XD)

   2.引入IOC容器：Unity(非XML配置方式)

   3.使用NHibernate 3.0(支持LINQ)和Fluent NHibernate(簡化NH配置難度)

   4.加入Service接口再結合ViewModel定義層數據協議(實現表現層和業(yè)務層分離，各司其職)

正題

　　回顧上兩篇文章，我們發(fā)現根本沒有Unity的蹤影，汗顏，寫著寫著發(fā)覺進度太慢，都沒用上的場合，但這篇文章會加入Unity來少SHOW一下用法，主要是來個拋磚引玉。

     這次項目由于想用MVC3來做，所以就直接開一個新的項目來展示了，放棄之前那個了，從需求到實現全過程慢慢回放，(*^__^*) 嘻嘻……，雖然簡單，但會很流暢，具有回溯性。

作為經常開發(fā)軟件的程序員，總所周知，未登錄的用戶功能模塊是最常見的模塊之一，我們就從未登錄用戶模塊入手來設計吧，由于名字太長，我習慣把它叫做游客模塊。廢話少說，我們先看看這次項目的總體結構圖。

幾個類庫，和一個WEB。簡單解析一下各個類庫的作用。Domain用來存放實體對象，而Infrastructure是提供一些框架基礎功能，Service是對外提供的應用服務，ServiceConcrete是Service服務的具體實現，UnitTest是單元測試用的，ViewModel是表現層的數據載體，Web就不用我墨跡了。XD

剛提到從需求入手，常見的游客模塊功能有登陸(LoginOn), 注冊(Register),找回密碼(FindBackPasswrod)等功能。多的就不細想了，主要是做一個需求參考，所以根據這些動賓結構的文字需求我們可以得出一個游客管理接口，如下圖。

也許你會覺得奇怪，為什么會有這么多奇怪參數和返回值，這里是因為我用到了ViewModel充當DTO，意圖是給表現層定義一批針對UI的數據協議，絕對分離表現層和業(yè)務層的關系，因為很多時候一個視覺看到的東西并不等于業(yè)務對象的所有信息，有可能是業(yè)務對象的一個子集，也有可能是多個業(yè)務對象的并集，面對如此不穩(wěn)定的UI視覺效果，我們應該為它定義出一套屬于它理解的模型，這樣面對UI的變化就會安逸很多了，如果你習慣把一些簡單類型作為方法參數，你就應該去重新定位你對層的理解，當然不否定簡單類型作為參數有時候是存在，但我的經驗告訴我，很多時候都不應該這么草率去使用簡單類型作為一個功能參數，至于為什么，真的是一言難盡~XD 我們順帶看看ViewModel的布局

我是根據模塊-功能來分類的，命名方式十分不優(yōu)雅，我也想不到更好的分類和命名方式了，如果你有更好的解決方式，可以告訴我。而注意的是，DTO開頭的模型在這里的意思是輸入型數據模型，而VO開頭的是展示型數據模型。因為我所理解的數據協議包含了輸入協議和輸出協議，雖然不一定并存，但一定會存其中一者，如果都不存在，就不會產生交互的需求了。XD

我們來看看Infrastructure的結構

因為我這里是用到NHibernate 作為ORM框架，所以很多處理都是圍繞NH。我們先回顧一下上篇提到的IRepository接口

不再詳細解釋其功能了。再來看看一個INHConfiguration，NHibernate配置接口，其意圖是隔離配置方式，因為我這里是用Fluent去配置的，有時候想用XML，所以~

我們再看看具體的配置實現

因為這里是使用到Fluent NHibernate的配置，所以知識點請沒學過的朋友自己查閱，不過從圖中可以看出，配置的方式很直觀，這里不詳細解釋用法，而使用Fluent的目的很簡單，我堅信“約定大約配置”這一道理，而且有靜態(tài)語言的代碼智能檢測功能，犯錯更從容~XD。PS:數據庫自動生成的，不用你手動去建數據庫的。

再轉回來看看NHibernateHelper這個輔助類

這里不解釋了，園子里都有很多文章介紹過。

看看我們具體的Repository實現類。

有部分用到NHibernate.Linq~然后我們關注一下我們的業(yè)務對象，雖然只有一個，，暫時的一個XD 然而這個User實體對象，是從多個用戶數據模型場景精化而來的，不是無中生有也不是拍腦袋的產物，它的屬性是從前面多個User ViewModel的屬性交集得出來的。

還有它的映射文件，也是用了Fluent的后果，不用再寫XML的映射文件了，個人覺得比較清爽和飄逸。

值得注意是，這里有一個Entity，主要作用是，復用對象標示，減少重復代碼，雖然代碼量不多XD，不過不提升成父類就太那個了！！

轉回來，我們看看具體的Service實現類，暫時只粗粗實現了一個功能，XD，由于時間關系，多多包含，(*^__^*) 嘻嘻……沒實現的我就打格仔了。

實現邏輯寫得比較簡單，或許有不當之處~請不要拍板XD

功能模塊和基礎模塊都做好了，當然Controller和View都自動出來了

說了這么久還沒看見Unity，想必你都和我急了，說實話就快到尾聲了~哈哈

這個IDendencyResolve是MVC3特有的，和以前重寫ControllerFactory一樣，都是為了可以方便對Controller實現依賴注入。

而我們的Unity當然是在Global文件上調用啦。

 只需要用RegisterType注冊一下對應的接口類型和實現類型，就可以實現依賴注入的效果，可以發(fā)現，基本上全程都沒出現 new對象，其實有一個地方出現了，(*^__^*) 嘻嘻……。總體來說使用IOC的初衷達到了，所有框架應用都不存在以往使用XML文件繁瑣的配置方式，個人感覺良好。

本篇結語

希望這篇博文對你有所啟發(fā)，而三篇系列就這樣結束了，再這之后，我打算繼續(xù)開一些擴展篇來圍繞今次這個個DEMO來展開，加入一些實際開發(fā)中常見的問題的處理方式，如事務處理，權限控制，登陸狀態(tài)檢測，前端技術等等，下篇將會介紹一下JQuery AJAX在MVC上的應用~敬請期待。