Android中MVC設計模式:
MVC設計模式是爲了讓編程工程項目層次化，使之分工明確，便於設計項目工程和後期修改維護。
M:model
實現具體的功能代碼，業務邏輯。
如：
com.sharpandroid.domain：實體模型層，存放在程序中調用到的實體類。
com.sharpandroid.service：業務模型層，存放在程序中調用到的業務邏輯。
V:view
實現界面UI。
Android很好地將顯示層抽離，並放入”res/”目錄中以XML的形式體現。雖然對於控件屬性修改可以通過代碼完成，但還是推薦將控件的屬性在XML中設置爲佳，遇到動態修改的內容再採用硬編碼的方式。這樣增加了程序的可讀性，也有利於軟件後期的維護。
main.xml、shownews.xml：佈局文件。
strings.xml：存放常量。
drawable：存放使用的圖片文件。
Control是Acticity的天職，你只要告訴Acticity做什麼，而至於怎麼做，那是模型層的事。
C:Control
作爲M和V的橋樑，使之有條理的協調工作。
Control是Acticity的天職，你只要告訴Acticity做什麼，而至於怎麼做，那是模型層的事。
若不使用MVC：
（1）這樣做帶來最明顯的缺點就是過分的耦合。試想一下，在設計初期，沒有遵循MVC進行嚴格的分層，而在開發中，當需要對一個方法或者一個佈局進行更改時，由於層與層之間的過分耦合，那麼你將面對的是”牽一髮而動全身”的修改過程。如果基於MVC設計應用，我們只要修改相應層，就達到了我們的目的。
（2）難以分工。在不使用MVC情況下，程序員要爲如何設計UI用戶界面頭疼不已，浪費大量的精力，而不能將重點放在覈心代碼的編寫上，降低開發效率。如果遵循MVC，就可以將視圖層交給美工處理，程序員可以更好地去關心核心代碼的編寫，不用再被繁瑣的佈局所困擾。雖然現在Android的佈局並不是十分複雜，可是隨着Android的發展，這必然是一個趨勢。
（3）不宜維護性。在不使用MVC情況下，即使能順利將其開發完成，但在開發過程中用戶可能對某一模塊不滿意，需要修改或者去除，有時需要添加新的模塊，這樣的事情，對於處理沒有使用MVC設計模式的程序，將會是多麼頭疼的事情。
（4）Android系統專門提供了”res/values/”目錄下的諸如strings.xml、colors.xml類型的文件，可以將我們的常量值寫入XML文件中，方便調用。這樣不僅節省資源，還便於對資源的管理。如果某變量需要修改，可以直接對strings.xml文件進行修改。否則，我們需要對整個應用中所有用到該變量的代碼進行修改。
