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