【Android】Android MVC結構的淺見【轉載】
http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf 寫道：
在Android應用程式中，我們不能夠非常清楚地區分MVC結構中的視圖部分和控制器部分。Android框架期望開發者們將Activity基礎類作為UI處理，這也就意味著一個Activity需要負責視圖與控制器兩個部分的任務。
利用觀察者模式將Model進行綁定處理。
Android近期學習總結——開發筆記 寫道
Android採用了典型的MVC結構。其表現如下：
View既可以通過xml(layout目錄下)生成，也可以通過硬編碼的方式直接通過代碼生成。對於xml中的View資源，可以在代碼中通過getViewById()的方法獲得。
Model既可以通過xml(values目錄下)生成，也可以硬編碼的方式直接在代碼中指定。View和Model通過Adapter來進行連接。典型的Adapter包括ArrayAdapter(可以Sort()操作)、CusorAdapter(從Cusor中查詢到資料來源),ListAdapter、SimpleAdapter(最常用)、SpinnerAdapter(它是一個介面，設置Spinner應用SimpleAdapter的setDropDownResource方法)。
談對android開發的認識 寫道
Android應用開發一般來說由四大塊構成 activity, intent, provider, broadcastreciver.
從這種結構上來看，android系統是提供了從顯示層到資料層到消息機制的一整套的應用開發方案，而且是一種比較先進的解決方案。
從寫android代碼的過程中，android項目整體是一種典型的MVC結構，非常類似於主要用於WEB開發的J2EE架構。
xml佈局檔是view相當於JSP頁面; activity和intent起到了controller的作用; provider對資料層做了良好的封裝，而且provider把資料管理的範疇從資料庫泛化到了資料的概念，不光管理資料記錄，只要是資料檔案(圖片、視頻、音效檔、所有其他的一切的file)都納入管理，且提供了資料共用的機制，這是比較出彩的地方; broadcastreceiver提供了一種良好的消息機制，使得一個應用不再是一個資訊孤島，而是和其他的應用、服務等構成了資訊網路，從而極大的豐富了應用的開發空間，給了應用開發者極大的想像創造的可能。
在看了上述討論後，我受益匪淺。按照以前開發RoR的經驗，總覺得如果僅僅將xml佈局看作View層未免太單薄，而且負責渲染與事件綁定的工作也全部落到了Activity的頭上，這看上去不太合理。不過另一方面說，這看上去不合理的原因是自己見識的太少以及教條主義的影響。
那麼究竟該如何劃分這幾層結構呢？我覺得可以換個思路出發，我們究竟該如何合理地組織一個Android應用程式呢？我們不必教條地、具有成見地將原先系統劃分結構帶入到這樣一個新的框架結構中，而是需要在這個特定結構中發揮其框架的效果：
• xml佈局負責將介面佈局做好，並且儘量做到合理分割與減少層次
• Activity做好控制項事件綁定與業務流程控制
• Intent做好Activity間的session傳遞管理
• 自己創建Model（可以通過Observer模式進行綁定處理、並且包裝好各種provider）將處理資料的工作做好。不建議簡單地將各個資料欄位散亂地存放在Activity周圍，而是借助資料Bean的思路存放在Model下面，這樣在Model資料項目變得龐大後難於管理與重構，而且這多為非面對物件的設計方案。
• Adapter是數據與呈現的粘合劑
以上是個人在做了個Android的一個小應用後的反思與看法，整體上層次是非常低的。在這次開發中，我看到了自己在做用戶端軟體方面的一些問題，先分享與大家，希望能夠共勉：
• 上手新框架時，成見較多，借助以前的思路機械搭建應用。這樣沒有合理發揮Android框架的優勢，做了很多無用功。
• 整個知識網路的整合上面有欠缺，在做RoR時能夠良好地利用Bean做資料傳遞與統一化工作。而在用戶端程式時，將資料欄位散亂的放在了Activity中。產生這個問題一方面來源於自己的懶惰，因為剛剛開始處理時欄位就一個，所以就直接放上去了；到後來資料項目激增，但是思路卻沒有變化。
• Observer模式是個不錯的方案，在應用開發中卻沒有應用。我覺得這也是在做RoR時的一些問題，和ASP.net不同（事件驅動，容易考慮到觀察者模式），RoR多為URL傳遞後行為觸發，各種行為被自然放在了control中。而在Android應用中，錯誤地將Activity簡單地當作了Control，將業務控制邏輯放在了裡面最後忘卻了觀察者模式。
• 測試->開發->重構，的模式可以進一步上升一個層次，對整個流程再重構，這樣不至於陷入思維陷阱。
轉載來源
在Android應用程式中，我們不能夠非常清楚地區分MVC結構中的視圖部分和控制器部分。Android框架期望開發者們將Activity基礎類作為UI處理，這也就意味著一個Activity需要負責視圖與控制器兩個部分的任務。
利用觀察者模式將Model進行綁定處理。
Android近期學習總結——開發筆記 寫道
Android採用了典型的MVC結構。其表現如下：
View既可以通過xml(layout目錄下)生成，也可以通過硬編碼的方式直接通過代碼生成。對於xml中的View資源，可以在代碼中通過getViewById()的方法獲得。
Model既可以通過xml(values目錄下)生成，也可以硬編碼的方式直接在代碼中指定。View和Model通過Adapter來進行連接。典型的Adapter包括ArrayAdapter(可以Sort()操作)、CusorAdapter(從Cusor中查詢到資料來源),ListAdapter、SimpleAdapter(最常用)、SpinnerAdapter(它是一個介面，設置Spinner應用SimpleAdapter的setDropDownResource方法)。
談對android開發的認識 寫道
Android應用開發一般來說由四大塊構成 activity, intent, provider, broadcastreciver.
從這種結構上來看，android系統是提供了從顯示層到資料層到消息機制的一整套的應用開發方案，而且是一種比較先進的解決方案。
從寫android代碼的過程中，android項目整體是一種典型的MVC結構，非常類似於主要用於WEB開發的J2EE架構。
xml佈局檔是view相當於JSP頁面; activity和intent起到了controller的作用; provider對資料層做了良好的封裝，而且provider把資料管理的範疇從資料庫泛化到了資料的概念，不光管理資料記錄，只要是資料檔案(圖片、視頻、音效檔、所有其他的一切的file)都納入管理，且提供了資料共用的機制，這是比較出彩的地方; broadcastreceiver提供了一種良好的消息機制，使得一個應用不再是一個資訊孤島，而是和其他的應用、服務等構成了資訊網路，從而極大的豐富了應用的開發空間，給了應用開發者極大的想像創造的可能。
在看了上述討論後，我受益匪淺。按照以前開發RoR的經驗，總覺得如果僅僅將xml佈局看作View層未免太單薄，而且負責渲染與事件綁定的工作也全部落到了Activity的頭上，這看上去不太合理。不過另一方面說，這看上去不合理的原因是自己見識的太少以及教條主義的影響。
那麼究竟該如何劃分這幾層結構呢？我覺得可以換個思路出發，我們究竟該如何合理地組織一個Android應用程式呢？我們不必教條地、具有成見地將原先系統劃分結構帶入到這樣一個新的框架結構中，而是需要在這個特定結構中發揮其框架的效果：
• xml佈局負責將介面佈局做好，並且儘量做到合理分割與減少層次
• Activity做好控制項事件綁定與業務流程控制
• Intent做好Activity間的session傳遞管理
• 自己創建Model（可以通過Observer模式進行綁定處理、並且包裝好各種provider）將處理資料的工作做好。不建議簡單地將各個資料欄位散亂地存放在Activity周圍，而是借助資料Bean的思路存放在Model下面，這樣在Model資料項目變得龐大後難於管理與重構，而且這多為非面對物件的設計方案。
• Adapter是數據與呈現的粘合劑
以上是個人在做了個Android的一個小應用後的反思與看法，整體上層次是非常低的。在這次開發中，我看到了自己在做用戶端軟體方面的一些問題，先分享與大家，希望能夠共勉：
• 上手新框架時，成見較多，借助以前的思路機械搭建應用。這樣沒有合理發揮Android框架的優勢，做了很多無用功。
• 整個知識網路的整合上面有欠缺，在做RoR時能夠良好地利用Bean做資料傳遞與統一化工作。而在用戶端程式時，將資料欄位散亂的放在了Activity中。產生這個問題一方面來源於自己的懶惰，因為剛剛開始處理時欄位就一個，所以就直接放上去了；到後來資料項目激增，但是思路卻沒有變化。
• Observer模式是個不錯的方案，在應用開發中卻沒有應用。我覺得這也是在做RoR時的一些問題，和ASP.net不同（事件驅動，容易考慮到觀察者模式），RoR多為URL傳遞後行為觸發，各種行為被自然放在了control中。而在Android應用中，錯誤地將Activity簡單地當作了Control，將業務控制邏輯放在了裡面最後忘卻了觀察者模式。
• 測試->開發->重構，的模式可以進一步上升一個層次，對整個流程再重構，這樣不至於陷入思維陷阱。
轉載來源
留言
張貼留言