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