標籤：
在Android開發中，比較流行的開發架構模式採用的是MVC架構模式，採用MVC模式的好處是便於UI介面部分的顯示和商務邏輯，資料處理分開。那麼問題來了，在Android項目的開發中哪些代碼來充當M,V,C角色呢？下面結合Android項目的具體結構對MVC for Android 做簡要剖析。
M（Model）模型層 適合做一些商務邏輯處理，比如對資料庫的存取操作、對網路等的資料請求操作、複雜的演算法、耗時的任務等都應該在Model裡面處理，當然對業務計算等操作也是必須放在該層的。
V（View）顯示層 應用程式層中處理資料顯示的部分。Android很好地將顯示層抽離，並放入“res/”目錄中以XML的形式體現，所以在Android中XML布局可以視為V層，顯示Model層的資料結果同時接收使用者輸入的資訊。
C（Controller）控制層 在Android中，Activity處理使用者互動問題，因此可以認為Activity是控制器，Activity讀取V視圖層的資料，控制使用者輸入，並向Model模型層發送資料請求。Control是Activity的天職，你只要告訴Activity做什麼，而至於怎麼做，那是模型層的事。這句話也就暗含了不要在Activity中寫過多邏輯代碼，要通過Activity交割Model商務邏輯層處理，這樣的另一個原因是Android中的Activity的回應時間是5s，如果耗時的操作放在這裡，程式就很容易被收掉。
如果不用MVC會怎樣？
- 這樣做帶來最明顯的缺點就是過分的耦合。試想一下，在設計初期，沒有遵循MVC進行嚴格的分層，而在開發中，當需要對一個方法或者一個布局變更時，由於層與層之間的過分耦合，那麼你將面對的是“牽一髮而動全身”的修改過程。如果基於MVC設計應用，我們只要修改相應層，就達到了我們的目的。
- 難以分工。在不適用MVC情況下，程式員要為如何設計UI使用者介面頭疼不已，浪費大量的精力，而不能將重點放在核心代碼的編寫上，降低開發效率。如果遵循MVC，就可以將視圖層交給美工處理，程式員可以更好地去關心核心代碼的編寫，不用再被繁瑣的布局所困擾。
- 不易維護性。在不使用MVC情況下，即使能順利將項目開發完成，但在開發過程中使用者可能對某一模組不滿意，需要修改或者去除，有時需要添加新的模組，這樣的事情，對於處理沒有使用MVC架構模式的程式，將會是多麼頭疼的事情。
- Android系統專門提供了"res/values/"目錄下的諸如strings.xml、colors.xml類型的檔案，可以將我們的常量值寫入XML檔案中，方便調用。這樣不僅節省資源，還便於對資源的管理。如果某變數需要修改，可以直接對strings.xml檔案進行修改。否則，我們需要對整個應用中所有用到該變數的代碼進行修改。
MVC for Android
