本文是對我在知乎乙個回答的整理，其中的內容大多是對我平時的閱讀和實踐的總結，希望對android的開發者有所幫助。但畢竟是個人的一些思考，難免有疏漏，也歡迎對本文的內容提出建議。
模型層（model）中的整體**量是最大的，一般由大量的package組成，針對這部分需要做的就是在程式設計的過程中，做好模組的劃分，進行介面隔離，在內部進行分層。
強化presenter的作用，將所有邏輯操作都放在presenter內也容易造成presenter內的**量過大，對於這點，我的方法是在ui層和presenter之間設定中介者mediator，將例如資料校驗、組裝在內的輕量級邏輯操作放在mediator中；在presenter和model之間使用**proxy；通過上述兩者分擔一部分presenter的邏輯操作，但整體框架的控制權還是在presenter手中。mediator和proxy不是必須的，只在presenter負擔過大時才建議使用。最終的架構如下圖所示：
aop(aspect-oriented programming, 面向切面程式設計)，誕生於上個世紀90年代，是對oop(object-oriented programming, 物件導向程式設計)的補充和完善。oop引入封裝、繼承和多型性等概念來建立一種物件層次結構，用以模擬公共行為的乙個集合。當我們需要為分散的物件引入公共行為的時候，oop則顯得無能為力。也就是說，oop允許你定義從上到下的關係，但並不適合定義從左到右的關係。例如日誌功能。日誌**往往水平地散布在所有物件層次中，而與它所散布到的物件的核心功能毫無關係。對於其他型別的**，如安全性、異常處理和透明的持續性也是如此。這種散布在各處的無關的**被稱為橫切（cross-cutting）**，在oop設計中，它導致了大量**的重複，而不利於各個模組的重用。而aop技術則恰恰相反，它利用一種稱為「橫切」的技術，剖解開封裝的物件內部，並將那些影響了多個類的公共行為封裝到乙個可重用模組，並將其名為「aspect」，即方面。所謂「方面」，簡單地說，就是將那些與業務無關，卻為業務模組所共同呼叫的邏輯或責任封裝起來，便於減少系統的重複**，降低模組間的耦合度，並有利於未來的可操作性和可維護性。
從三層架構到mvc, mvp
mvc, mvp以及model2
gof等。
Android App整體架構設計的思考
本文是對我在知乎乙個回答的整理，其中的內容大多是對我平時的閱讀和實踐的總結，希望對android的開發者有所幫助。但畢竟是個人的一些思考，難免有疏漏，也歡迎對本文的內容提出建議。1.架構設計的目的 2.基於mvp的架構設計思路 2.1 什麼是mvp?2.2 mvp架構存在的問題 模型層 model ...
spring 整體架構
1.core container 核心容器 core 包含spring框架的核心工具類 beans 包含訪問配置檔案 建立和管理bean 以及進行ioc di 相關操作的所有類 context 整合beans為spring框架提供大量的擴充套件 expression language 提供表示式語言...
索引整體架構
lucene將索引文件的過程設計成兩個階段，寫入記憶體階段和寫入硬碟階段。在寫入記憶體階段，lucene通過indexchain把document分解並把相關資訊儲存到記憶體中,等到滿足flush條件 記憶體容量或者文件個數積累到臨界值 就通過indexchain把記憶體中的資料寫入硬碟。index...