MVP實戰心得(一)

我的心得:

對於大項目,大公司,人員不少的話,很是不錯,模塊清楚,分工明確.
對於小項目,小公司,我的獨立開發,那就很不友好了
複製代碼

一我的寫起來會感受代碼很是很是多,很繁瑣,簡直坑爹. 費時間的地方以下:

1.大量的接口

寫完界面還得想好view接口有哪些方法, presenter會有哪些方法 modle比較好解決,基本就是一些網絡請求接口(若是用retrofit的話)

2.基類的封裝

若是用mvc,那麼只要寫好baseactivity和basefragment, 但用mvp,就得多些東西了:

BaseView
BasePresenter
BaseFragmentView,BaseActivityView 等等
複製代碼

3.寫到一半發現須要某個對象或者方法

好比我要在fragment的presenterImpl中拿到FragmentManager來作一些事 這是我一開始沒想到的 那麼我就得在對應view中添加getFragmentmanager()的方法 而這個方法其實應該放到BaseFragmentView接口中. 而base類通常是不容許隨便改的

好比我如今在BasePresenter裏面寫了onCreate(),onDestroy() 來對應相應fragment,activity的onCreate(),onDestroy() 若是之後須要用其餘生命週期了,同上就得加接口.

4.太多的實現類:

一個頁面至少須要:1個activity/fragment,1個presenterImpl,1個contract,1個modleImpl,1個bean,5個類, 而mvc只須要:1個activity/fragment,1個bean,完事了... 假如1個app的界面是30個的話,mvp會有150個類.而用mvc就60個

總結一下:

1.mvp用起來可能沒有你想的那麼和諧,友好,確定會一邊寫一邊改,不過通過一段時間修修改改,習慣就行了.

2.可能會寫到一半發現須要加接口改接口,由於persenter跟view打交道全靠寫接口.隔離性是很好,但寫起來就沒那麼方便了.

3.一改動可能就要改好幾個類.切多了人都了暈.

附上github的mvp示例: mvpDemp