使用mvp深度解耦
如图所示 我们可以看到 View
和 Model
没有任何联系,在我们传统的 mvc
设计模式中,view
经常会去操作Model
.
而在MVP
里,Presenter
完全把Model
和View
进行了分离,主要的程序逻辑在Presenter
里实现。而且,Presenter
与具体的View
是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更View
时候可以保持Presenter
的不变,即重用! 不仅如此,我们还可以编写测试用的View
,模拟用户的各种操作,从而实现对Presenter
的测试--而不需要使用自动化的测试工具。 我们甚至可以在Model
和View
都没有完成时候,就可以通过编写Mock Object
(即实现了Model
和View
的接口,但没有具体的内容的)来测试Presenter
的逻辑。
整个类图分为3块区域
左边
IBaseView
,IWeatherView
,WeatherActivity
划分为View
层。
IBaseView
是为了定义一些公用的操作方法,比如showLoading
这样的方法
IWeatherView
实现IBaseView
并定义了天气界面要操作的方法。
WeatherActivity
实现了IWeatherView
中间
BasePresenter
,WeatherPresenter
,DataCallback
属于Presenter
层
BasePresenter
是所有 presenter 的父类。
WeatherPresenter
定义并实现了对应View 要具体操作的事项。
DataCallback
是一个泛型接口,定义要获取的数据类型,在presenter 和 Model 两层之间解耦。
最右边
BaseModel
,WeatherModel
,ResultCallback
属于model
层
BaseModel
是所有 Model 的父类。
WeatehrModel
主要是封装view传递过来的参数并向业务服务器发送request,当然还要负责返回数据的解析。
HttpHelper
主要是封装了网络请求。
ResultCallback
是在model 层和 http层进行解耦。
在整个设计中,用了两个 interface 来解耦。ResultCallback
让httpHelper
独立出来,让它完全作为一个工具类,只负责发送请求,我们随时可以替换这一层的实现而不会有别的影响。Datacallback
让Model
变成正在的数据持久层,入参的封装,返回数据的封装,都可以放在这一层,在Presenter
直接拿到界面想要的 javabean。