本著每隔一年就得折騰一個新框架的習慣，近期對以前框架繁瑣的結構進行了一些反思，加上打算新框架放棄使用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