整個世界林林種種,把所有的事情都划分為對立的兩個面。
每個人都渴望的財富划分為富有和貧窮,身高被划分為高和矮,身材被划分為胖和瘦,等等。
我們總是感嘆,有錢人的生活我不懂;有錢人又何嘗能懂我們每天起早貪黑的工作,總是做不到來一次說走就走的旅行。
程序員的生活也是這樣。當你覺得自己學有所成是去面試一家互聯網公司,很可能面臨的是一盆冷水潑下。
面試的人員可能委婉的告訴你：我們是企業級開發,你那些個人演示的項目經驗在我們這里的實際項目中幾乎沒用;
我們做的是分布式應用,分布式你懂嗎？我們的應用都是要上雲的,雲計算你懂嗎？
你一頭霧水在心里憤憤不平又能怎么樣？只能感嘆,你們的代碼世界我不懂。
世界已經是這樣了，我們也沒有能力消除貧困,只能盡力減少貧富差距。
項目開發也是一樣,企業級復雜系統需求在哪里,我們不可能去減少和改變需求,我努力的方向是開發一些工具,作為橋梁簡化企業級或者分布式開發,讓它和我們的簡單應用開發盡可能的相似。
1、 Asp.net MVc模塊化開發之分區擴展框架(送源碼)
2、 Asp.net Mvc模塊化開發之“開啟模塊開發、調試的簡單愉快之旅”
3、 Asp.net Mvc模塊化開發之“邏輯(項目)復用”
3.1、 不同角色或者權限的邏輯(項目)復用(分區過濾器的應用)
3.2、 不同業務的邏輯(項目)復用(DI(依賴注入)的應用)
4、 Asp.net Mvc模塊化開發之“項目(分區)拆分”
5、 Asp.net Mvc模塊化開發之“部分版本部分模塊更新(上線)”
廢話說了不少了，還是盡快開啟我們的模塊開發之旅吧。
一、先搭分區項目配置
1、先建一個普通的Mvc(4.0)項目,並添加所需引用(分區擴展框架、Unity容器(2.0)、企業庫(4.0))
2、配置容器和分區
2.1 修改路由配置類為分區類
以上修改后的分區配置(行路由)類我還特意保留老的路由規則,除了方法簽名就是直接復制路由規則了,easy吧。
2.2 新建容器配置文件(unity.config),並在其中配置分區(增加一個空的依賴注入容器備用)
如圖我們使用當前項目名(MvcApplication1)作為分區名和分區路徑建了一個分區(我習慣把這個配置文件都放在項目下的ConfigFiles文件夾下,大家可以按照自己的習慣放在任意位置)
需要注意的是,這個分區的路徑配置(path)是我特意注釋的,也就是沒有配置路徑,沒有配置路徑就是默認路徑,也就是和默認Mvc項目一樣的瀏覽路徑
2.3 注釋Global.asax.cs中關於路由和過濾器注冊的代碼
2.4 在Web.config中增加調用unity配置的節點
這里把Unity配置拆分為獨立文件,這樣可以有效減少Web.config的大小和獨立性,建議盡量保持干凈的Web.config,每個配置文件盡量做到"職責單一",對程序的穩定性和日后查找問題是有很大幫助的。
2.5 在Web.config中的system.webServer和system.web增加分區擴展框架的httpModule
system.web的httpModules在經典模式下起作用,system.webServer的modules在集成模式下起作用,如果不確定兩個都配上就Ok了。這個在另一片文章也有說過。
2.6 配置完了,現在加一個測試控制試一下
現在瀏覽測試一下(直接F5):
看到這個界面那是滿滿的欣悅,我們已經成功擴展了Mvc分區項目,沒有使用默認的路由方式和過濾器方式
有人說,默認新建一個Mvc項目直接F5就能看到你這個界面,你這光配置就要6個步驟,太麻煩了。
大家有沒有發現以上步驟都是機械性的簡單配置,熟悉的人只要一頓ctrl+C和ctrl+V在幾分鍾內即可完成,不可謂不簡單
當然也可以做一個代碼生成工具(T4模板、CodeSmith等),一鍵生成。甚至可以可以做一個擴展后的Mvc項目模板,和默認的Mvc項目一樣生成,一樣簡單。在這里我就不過多展開了。
二、我們繼續分區框架的探討
1、 有人可能說,不是說好的模塊話開發嗎？不可能每個模塊都是根目錄,這樣會沖突的。
哈哈這個好說話,分區路徑是可以配置的,只要設置一個分區路徑就ok了
不只是這樣，同一個開發項目還可以配置兩個(及更多都行)分區,其中一個配置默認路徑，開發調試方便;一個配置模擬部署路徑,隨時預覽部署后的效果>
以下是分區配置圖:
以上分區配置節點都是放在Mvc這個容器里面的,這個是在分區框架中寫四的,必須這樣配置才可以生效(對於這個問題分區框架介紹及源碼那篇文章中有更多表述)
我們來看一下路由表：
和前面一個配置相比,前面多了一個分區配置節點,為神馬在前面?因為避免路由規則沖突,如果按默認分區的路由規則,/Test/就會匹配為默認分區的一個控制器，而不是一個分區下的默認控制器。
以下是兩個分區的各自效果:
哈哈，還不錯吧。即可以和默認Mvc項目一樣簡單調試,也不耽誤模擬部署路徑。
2、有人說兩個分區的視圖(Views)都放在根目錄下不科學啊，現實部署環境這樣會沖突的。
是啊,視圖沖突不解決，怎么能稱得上模塊化開發啊？其實這個Asp.net Mvc框架已經為我們解決好了。
2.1 我們來建一個Action(Detail)來試一下,先不要建視圖,讓他出錯,因為這個錯誤信息中包含大量的有用信息
Action代碼很簡單:
瀏覽效果如下圖:
出錯了,錯了不要怕,我們要的就是這些錯誤信息
2.2 我們來分析一下這個錯誤信息
這個因為Mvc框架找不到適合的視圖報的錯,其實就是指引我們按以上規則去存放視圖文件
前面一片aspx和ascx(web form用戶控件),我們可以無視了,只要把.cshtml的路徑找出來(.vbhtml是為習慣用vb語言的,大多數人都主要是用C#,可以無視)
分區視圖首先查找路徑: ~/Areas/{areaName}/Views/{controllerName}/{actionName}.cshtml
其次查找當前分區的共享(Shared)文件夾: ~/Areas/{areaName}/Views/Shared/{actionName}.cshtml
再次忽略分區在根目錄下的視圖文件夾查找: ~/Views/{controllerName}/{actionName}.cshtml
最后在在根目錄下的共享視圖文件夾查找:~/Views/Shared/{actionName}.cshtml
只要掌握好以上規律,可以輕松避免視圖沖突的問題
我們還發現Mvc框架如果找不到分區文件夾(含有符合要求的視圖)會按普通項目的視圖路徑查找視圖,這更方便我們按普通項目一下開發模塊化(分區)項目
只要我們部署的時候把對應分區項目里面的視圖復制到站點對應的分區視圖文件夾中。
2.3 其實這個視圖路徑是由ViewEngines.Engines來配置的
其一、可以看出Mvc是優先支持WebForm視圖,可以如果性能偏執狂可以把WebForm視圖引擎移除掉
其二、分區視圖和默認視圖的路徑都是可以配置的,需要的人也可以定制;我認為Razor視圖引擎的默認規則已經夠我們用了,默認就好了
2.4 讓我們以兩種視圖部署的效果來結束這個小話題
以上兩個分區的Action(Detail)的視圖,一個放在分區視圖路徑,一個放在普通視圖路徑都能正常顯示
再次強調實際開發中沒必要在項目中建分區路徑(Areas及下面分區和視圖文件夾),只要按普通Mvc項目開發即可,只要部署的時候復制到對應的分區文件夾就可以了。
三、分區擴展框架繼續挖掘
以上是把使用分區框架開發怎么盡量往Mvc普通項目上靠,最多也就能說明,擴展后和沒擴展"沒什么區別",有人要開罵了,你折騰個啥啊,你圖啥啊。
"沒區別"是偷換概念的狡辯,如果擴展的Mvc分區框架只能做到這里,確實有不小的遺憾,現在開始挖掘擴展分區框架給我開發項目帶來的便利性。
1、簡單、高效、貼心的分區配置
1.1 在自己的分區類上增加需要的配置項
分區類型修改:
配置文件修改:
測試程序修改驗證:
以上通過RouteConfig.GetCurrent()
預覽看效果:
效果出來了，還不錯吧。
有人還是會說,說好的"簡單"呢？折騰一圈,我還不如在Web.Config的appSettings配置一個PageSize節點
這樣配置方式是有"問題"，但對於appSettings還是有很大優勢;
其一、我們要做的是模塊化開發,是要做好和其他項目部署到同一個站點的准備。如果別的項目也正好配置了一個PageSize節點就沖突。
其二、我前文已經說了,我是要做好同一個項目在同一站點部署多個分區的准備的,前面效果已經出來的,兩個分區的條數一個是18一個是10,相互不影響。
我們能不能做到更加簡單,當然可以,請繼續
1.2 使用依賴注入容器配置
增加一個測試的控制器，增加一個PageSize屬性,並且聲明為Dependency,意思是通過ListPageSize節點，Action代碼也比上面一個例子簡單多了,不用獲取當前分區信息
看上圖配置也有變化,為了區分兩個分區,再增加了一個依賴注入容器，依賴注入容器分別配置了一個節點ListPageSize和控制器相對應
上效果圖:
是不是簡單多了,雖然簡單,里面包含的意義是非常豐富的。
其一、控制器需要什么配置(對象)就定義對應的屬性，並不需要定義獲取在控制器中定義和調用獲取該配置的方法
其二、每個分區有獨立的依賴注入空間(容器),不會出現分區間的沖突
其三、每個配置項在容器中是獨立的,可以直接動態增加不需要破壞原有結構(比如前面一個例子修改了分區配置類,如果配置項目太多,分區類將過於復雜難以維護)
其四、需要調用配置的地方和配置項目可以直接排列組合產生關系,配置項目可以高度服用,調用點(控制器)也可以隨時調整,不會破壞整體項目結構。
其實以上開發的便利來源於分區擴展框架的分區DI(依賴注入)功能,這個在分區框架介紹及源碼那篇文章中也有表述表述,這個話題還有必要新開以便文章繼續挖掘。
這篇文章終於寫完了。下載源碼。這篇文章和前面的分區框架介紹及源碼那篇文章有很多相似的內容。這篇文章主要目的是說明使用分區框架進行分模塊開發如何和普通項目一樣簡單及分區框架提供的更多便利。其中有一些Mvc和分區框架細化的探討可以算作一點偏題。我的出發點是盡量使大家即"知其然"還"知其所以然"做的部分展開。