Asp.Net MVC +EF CodeFirst+多層程序設計

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

Blogs Code