依據我的理解，畫了個圖
這次又看了下 較複雜點的樣例。
往往乙個專案有多個部份，我們可以按功能分成幾個activity, 每乙個activity有自己的view和資料model，因此也有自己的邏輯 presenter,, 假設真正可以依照 m v p模式來組建乙個project，那麼整個專案思路將會十分清晰，並且每乙個mvp 三個方面的工作量都會很少，並且能邏輯清晰地去寫**。
這次認為有點亂亂的，不知道要怎樣表達，也沒再學到很多其它東西了。只是畫了個圖，以後看到也會更清晰了。。。。以下就借鑑一下別人的總結吧。。。。
在mvp裡，presenter全然把model和view進行了分離，基本的程式邏輯在presenter裡實現。並且，presenter與詳細的view是沒有直接關聯的，而是通過定義好的介面進行互動，從而使得在變更view時候能夠保持presenter的不變，即重用！
mvp的長處
1、模型與檢視全然分離，我們能夠改動檢視而不影響模型。
2、能夠更高效地使用模型，由於全部的互動都發生在乙個地方 —— presenter內部。
3、我們能夠將乙個presener用於多個檢視，而不須要改變presenter的邏輯。這個特性很的實用，由於檢視的變化總是比模型的變化頻繁。
4、假設我們把邏輯放在presenter中，那麼我們就能夠脫離使用者介面來測試這些邏輯（單元測試）。
mvp的缺點
因為對檢視的渲染放在了presenter中，所以檢視和persenter的互動會過於頻繁。另一點須要明確，假設presenter過多地渲染了檢視，往往會使得它與特定的檢視的聯絡過於緊密。一旦檢視須要變更，那麼presenter也須要變更了。比方說，原本用來呈現html的presenter如今也須要用於呈現pdf了，那麼檢視非常有可能也須要變更。
mcp與mvc的不同
MVC與MVP（僅限個人的理解）
mvc分為 model 資料抽象 view 檢視 controller 控制器 的三層架構。接下來我們分別來一一解析每一層所對應的職責分別是什麼。窗框 窗架 玻璃 玻璃上的窗花 優點 邏輯清晰，controller層和view層在一起的 在乙個類裡面，在乙個activity或者fragment 層次...
MVP模式的理解
mvp分為model，view，presenter分別對應模型層 實體模型，業務邏輯 檢視層 activity，fragment p層 連線模型層與檢視層，控制互動 至此就是乙個簡單的mvp模式實施過程。可能會不理解，乙個簡單的登入操作定義這麼多的介面，這麼多的類是不是有點畫蛇添足，對於小型的專案來...
MVP模式的學習，個人筆記
mvc模式 檢視 view 使用者介面。控制器 controller 業務邏輯模型 model 資料訪問 通訊方式 view 傳送指令到 controller controller 完成業務邏輯後，要求 model 改變狀態 model 將新的資料傳送到 view，使用者得到反饋 mvp模式 m m...