? ? ? 最早學編程的時候看過一些書，印象深刻的一本書《設計模式解析》，那本書給我后來的工作提供了很大的幫助。
他叫我站在問題模型的立場上指定解決方法，也教會了我軟件設計中每個問題都可以細化到到不可再分割的原子性。
在那書以后看到過一些設計模式的書出現。由于本人比較崇尚于權威或者說正統性的學術性書籍，沒怎么看其他本書。
最近一些年在網上看到過一些博客中把MVC說成設計模式，這個說法是錯誤的，MVC實際是軟件架構模式。
筆者可以毫不客氣的說，工作幾年以后，有一些人說MVC是設計模式，基本上是濫竽充數的程序員。
因為mvc并沒有設計模式中那種問題場景原型，他是一個軟件架構的泛化思想模型，比如工廠模式他可以解決需求更新時頻繁
維護方法代碼，只要傳入參數，他就給你對象，比如java中的用class.forname來裝載類。
? ? 筆者讀書不多，對于MVC的粗淺理解如下，供大家參考：
? ? MVC是一種軟件架構模式，他模擬人類社會分工，通過分工協作來完成一件事，完成這件事可能需要很多種工種，這里我們可以把
這些工作按角色來理解，理解成軟件中的各個層。
? ? 比如一個工程項目，公司老板安排設計人員去做標書，標書做完投標，然后把工程轉給技術部項目經理，項目經理安排技術人員去安裝，
技術人員安裝好以后反饋給項目經理，項目經理向老板匯報這個標已經完成，至此一個項目結束。
? ? 這個流程中：安排、轉、匯報幾個詞語大概反應了一個完整項目中各個角色之間交互的特點，即任務調度及分發，以及
任務結果反饋。
一個項目中如果用到了mvc架構模式，不管項目大小，按群體/角色/職責分工大概有Model層，Controller層，View層。
Model可以理解為基層，做一些苦力，基礎性的工作。
Controller可以理解為管理層，他們通常負責下發命令、調度任務
View層可以理解為用戶界面及用戶交互層。
?
我們剛剛舉例的工程項目中：老板、項目經理他們是Controller層，一個是下發命令，一個調度任務
其中設計部角色 以及技術人員他們是Model層，他們是做基礎工作的，他們這一層有一些粗糙的接口，可以和其他角色的人
來交流反饋任務結果。
篇博客臨時有點想法，算是吐槽，關于View層筆者沒有想到詳細的描述方式。
?
在軟件MVC架構中，我們的Model，View，Controller層大家都能劃分清楚吧，網上教程很多。
筆者的理解是，不管項目中有沒有MVC框架，合理的MVC框架設計應該遵循以下原則：
M層數據持久層，負責與數據庫通信，這一層包含數據模型實體類，以及一些CRUD方法。
C層主要負責調度任務，得到V層需求下發命令，最多出現的應該是把任務轉發給其他類處理。
例如
? DataStoreBLL dbll = new DataStoreBLL();
?dbll.doSave(Entity entity){
? ? DataStoreDAL dbal = new DataStoreDAL();
? ? ?dbal.doSave(entity);
}
實際數據持久化任務通過BLL轉發給DAL來處理，BLL只得到處理結果。
C層不應該出現數據庫操作代碼，例如jdbc的getConnection
View層負責與用戶交互，展示處理結果給用戶看，可以是web ui，cui，gui，app ui等
各個層之間通信應依賴于抽象（接口或者抽象類）。
??
