MVC到底怎麼分層

出處：

mvc，在程式中乙個永遠離不開的話題。由於層次架構，在程式設計之初就必須形成，對程式整體走向與把握起著十分重要的作用。然而總讓人困惑的是：mvc到底怎麼分層！

那麼就先對我自己認為比較理想的分層方法說說吧，如果大家有什麼意見，歡迎多多指點。

view層/ui層（介面層）：

1. 介面中所有控制項必要的格式判斷。

2. 蒐集介面中所有控制項資訊，並將之傳入controller/bll層。（最重要的功能）

controller/bll層（業務邏輯層）：

1. 接收介面層的資料。

2. 資料型別格式的轉換。

3. 處理業務邏輯。如決定如何呼叫以及組織model/dal層的方法（增刪改查），決定例項化的物件（角色），許可權的判斷控制等。（最重要的功能）。

model/dal層（資料訪問層）：

1. 提供對資料庫基本操作訪問的方法或介面（增刪改查）。

2. 提供對特定類的具有針對性的方法或介面。

3. 對資料庫訪問類的組織和管理。

對於我們來說，爭議最大的地方便是bll層。其實都知道是處理業務邏輯的，可是，邏輯？到底是什麼邏輯呢？邏輯判斷到底放在哪？

bll層的乙個設計準則是：對上層提供最為簡單最為明確最為實用的方法。換句話說，就是提供的方法盡量少的且功能強大。如果你提供的方法越多，就意味著越複雜，上層用起來就越繁瑣，對上層人員十分不便。如果方法越少，那麼這個bll就越有通用性，也就是說可復用的程度就大增，對於介面層的結構布局也起到統一的作用。

還有很多人，bll層就直接返回dal層的方法，如 return 類名.方法()。這樣一來bll層名存實亡，存在的價值就根本沒有了（完全可以去掉），這樣形成的架構，就看似頭重腳輕，架構的穩定性、靈活性、拓展性十分差。其實我想說，這是完全錯誤的做法。mvc架構其實就好比乙個金字塔，如下圖：

對於我們現在做的web開發模式的教務系統，我認為bll層在設計上就有很大的問題，採用的便是頭重腳輕的錯誤做法，而且web開發的介面層本來就相對於b/s的複雜，在給加上全部複雜的判斷，任務可謂是相當的重。這樣介面層出錯的機率也隨之增加。

bll層其實應該是需要重構的，但是現在既然都這樣開始動工了，也沒時間再改來改去的，這次就這樣好了，下次再多多注意吧。