本着每隔一年就得折騰一個新框架的習慣，近期對以前框架繁瑣的結構進行了一些反思，加上打算新框架放棄使用EXTJS，也深入研究了下Asp.net MVC 4。在此給大家匯報一下，也希望大伙提出寶貴意見。
先回顧一下我們以前的框架分層和目錄結構：
上圖可以看出，基本是按照DDD的路子去划分項目的分層的，每層一個項目。
點開業務領域層看下：
如上圖，業務領域層，數據訪問層，應用層是采用面向接口編程。系統中有大量的單一實現的接口。
接下來我們再到展現層看看：
如上圖，由於系統采用EXTJS做UI，所以會有大量的JS文件存在。
這個設計用了將近兩年，大小項目將近10個。開發體驗下我有如下不爽：
1.關於接口：由於采用面向接口的編程方法。單一實現的接口過多，實際用處不大。但導致“轉到定義”非常麻煩，只能轉到接口，具體實現代碼得手動去找。雖然ReSharper支持直接轉到具體實現，但是這貨裝上之后特別慢，很多人都不愛用。而且大量無聊的接口也增加不少代碼量和新建文件的時間。
2.由於是按照邏輯分層去划分的項目文件夾，導致做一個功能模塊的開發人員需要頻繁從各個分層文件夾去定位相關文件。項目大了之后找起來非常費勁。比如你得在基礎設施層項目才能找到這個模塊的數據訪問代碼，在業務邏輯層項目才能找到這個模塊的業務邏輯和實體，還有應用服務層、Controller、View、Javascirpt.....做一個功能模塊得把這些項目和目錄找個遍。非常蛋疼～
在做新框架設計的時候我決定解決掉這兩個讓我深惡痛絕的問題！
1.去掉單一實現的接口！這玩意用了這么多年，在一些具體業務邏輯上一點用都沒有！所以在當前設計如果一個接口只對應一個具體實現的情況下，堅決干掉這個接口。等有多態需求的時候再加接口其實也不遲。
2.新的框架打算一個模塊一個文件夾，這個模塊所有相關的東西都在這個文件內，而不是分散到各個分層中，如下圖：
"DropDown"是一個系統下拉選項維護的模塊
Repositories-數據訪問代碼
Models-實體代碼
Services-業務邏輯代碼
ViewModels-展現層用視圖模型代碼
Controllers-MVC 的控制器
Views-MVC的Razer引擎頁
Scripts-這個模塊相關的JS文件
Images-這個模塊相關的圖片文件
如此，你是這個模塊的開發人員你可以這樣“限定為此范圍”：
你看到的將是這樣：
整個視野非常干凈，你可以集中精力干你自己的事了！
接下來我們看看新框架整體的結構，只有三個項目！！！：
Zen.Core-系統的功能模塊實現都放在這個項目里，這個項目是一個類庫
Zen.Framework-基礎框架，公共類
Zen.Web-網站宿主，但這個網站基本是空的！因為我們把每個模塊的Controller,View,Js文件,甚至圖片,樣式文件都放在了Zen.Core項目里的模塊目錄里！
具體是這么做到的呢～請聽下回分解...........
上一篇寫的太水....放不到首頁~大伙也幫忙看下提下意見～猛擊->大伙看看這個界面風格咋樣...
懶的分解了，上傳源碼自己看吧～注意webconfig文件～我去掉了packages文件夾的第三方引用 要不太大了...用360解壓縮～猛擊->Zen.7z