我的第一个项目是使用的MVP模式,但当时还不太懂,让Presenter干了Model的事-加载数据,并不能说这么做是错的,因为是小公司,小项目,这样做更快,页面逻辑也清晰,所以还可以。
第二个项目是外包公司的项目,老员工使用了MVC模式,加上了EvenBus传递数据。当不用定义繁杂的接口时,开发速度是更快的,两个接手的项目都是如此。
我产生了疑问,“为什么要在项目中使用MVP模式,而不是开发更快的MVC,或者是自己规划的模式”。
我喜欢用MVP模式,我在小公司做小项目,能实际感觉到MVP的优点就是“可读性高、任务分化”,当我使用MVC模式写了一个复杂的地图页时,各种页面逻辑、业务逻辑、数据逻辑塞在Activity中,不仅导致文件很大,甚至连编写这个文件时都有卡顿,卡的受不了了,于是我把它重构为MVP模式,主要的目的是为了让Activity文件变小,定义了V的接口,使Activity的可读性变强了、处理逻辑清晰了。
那么当一个页面并不是那么大,能够轻松在Activity中完成所有的逻辑时,还有必要使用MVP吗?
比如登录页,逻辑并不多,用不用MVP可读性都是那样,文件大小也不需要用MVP分化,那么我就没有使用MVP的理由了。
而关于一直以来我忽略的MVP中P和M的分级,将任务分化的好处是可以清晰的处理每个任务的发起和结果,定义一个单独的Module带来的好处就是清晰的处理数据,当对数据的操作较多时,应当定义一个Module来理清逻辑,那么当对数据的操作并不多时,就没必要创建Module了。
18/6/20 新加- 当经历总是要改页面时,这个项目的登录页已经改了三次了!,使用MVP吧,、至少不用改逻辑。