1.概述
這是一個基於個人博客的一個項目，雖然博客根本沒必要做這么復雜的設計。但是公司有需求，所以先自己弄個項目練練手。項目需要滿足下列需求
1.層與層之間需要解耦，在后期上線更新維護時不需要覆蓋，只需要更新局部dll即可，也就是插件機制
2.代碼安全性，公司有找外包公司要些人，但是又不想讓他們得到所有代碼，就需要利用接口來規范開發。
3.一開始沒有完整的需求說明和數據庫設計文檔。我們是輕文檔開發，也就是說在沒有完全上線之前需求隨時可能更改，而且數據庫一開始也沒有設計好，而是開發一點添加一點，也隨時會更換需求。
為了保證以上要點，我們就需要搭建一個非常具有靈活性的系統，對一個剛剛開始參加.net開發工作的我來說卻是具有很大挑戰性，雖然之前也有受過高人指點。
2.程序設計
在程序設計時，我考慮到以上需求，我大致分了一下這些層。
1.實體模型層：CodeFirst實體對象
2.數據訪問層：DBContext對象，其實在我接觸EF之后就對數據訪問層的概念就不太一樣了，我現在都覺得數據訪問層都沒什么太大必要。因為不需要寫Sql語句了，都是lambda表達式。這是我一個疑問，大家可以一起討論下
3.數據庫訪問接口層：規范數據庫訪問層
4.數據庫訪問層工廠：這里我可以通過反射來反射出數據訪問層的實例
5.業務邏輯層：業務邏輯代碼
6.業務邏輯接口：規范業務邏輯
7.業務邏輯工廠：反射業務邏輯實例
8.MVC：前台展示
1.通過上面我們可以發現，層與層之間是解耦了，比如說我按照某個層的接口規范寫好了一個dll，然后更新好服務器，無需將整個項目編譯，也無需將整個項目重新覆蓋，只需要修改下反射的配置文件即可，也不會影響到網站的正常運行，這才是我要的效果。
2.接口規范些好后，也無需編碼人員將整個項目都拿到手，只要自己按照接口規范寫好代碼，放到測試環境中一測試就OK了。這樣對於保證公司代碼安全性還是有一定作用的。
3.通過CodeFirst我們可以比較輕松的更換需求，而且也不用一開始就把所有需求羅列出來，然后設計數據庫，我們可以一邊做功能的時候一邊來增加表。
以上思路應該比較適合大眾化，中小項目按照這樣的設計應該沒什么問題。大家如果有什么好的建議或者發現有什么不對的地方，還請提出來，以免誤導了他人。
Email：luozhiqiang@cidtech.cn