个人心得:
对于大项目,大公司,人员很多的话,非常不错,模块清楚,分工明确.
对于小项目,小公司,个人独立开发,那就很不友好了
一个人写起来会感觉代码非常非常多,很繁琐,简直坑爹.
费时间的地方如下:
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
