在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文件進行修改。否則，我們需要對整個應用中所有用到該變量的代碼進行修改。