框架是代码的重用,可扩展。举几个简单的例子。Spring架构,Struts架构。
设计模式是设计的重用,是一种抽象的设计方法。例如MVC,MVP,MVVM。
下面,我们以android开发为例,简单比较一下三种不同的设计模式。
MVC是指Modle,View和Controller,将界面,业务逻辑和控制器分开,是一种低耦合的设计方式,适用于简单应用开发。
举个简单的例子。android中的各种控件,即为View。例如,一个Button。如果这个Button用于获取服务器信息,我们可以将具体功能实现封装成一个功能类,叫做HttpUtil。并将获取的服务器信息,存放在ServerResponse类中。那么,HttpUtil和ServerResponse即为Modle。那么谁是Controller呢?Activity即为Controller,它将Modle和View连接起来。点击Button,将触发Activity的onClickLisener方法,从而进一步触发HttpUtil类。HttpUtil在获取结果后,将其封装为ServerResponse,ServerResponse显示至相应控件。
这种设计模式最为简单,但问题有三。
(1)View与Modle(ServerResponse类)相互可见,耦合度高。
(2)如果程序复杂,那么Activity这个Controller将十分繁琐复杂,不容易维护。
(3)Activity角色模糊,View或Modle。
因此,从MVC的基础上,衍生出了MVP模式。
P是指Presenter,即实现者,功能与Controller类似。Presenter实质为Interface类的运用,用于降低M,V,C间的耦合度,主旨是为Activity或Fragemnt瘦身。
Activity或Fragment瘦身后,应只包含setListener,生命周期控制,View接口实现,init以及Presenter的调用。而具体的操作,都在Presenter Implimentation类中实现。
经典的MVP模式,基本上包括6个部分
(1)View接口
View接口,用于定义View的更新逻辑,这个接口需要在Acitivity中实现。比如,显示进度条,隐藏进度条,控件text更新等。
(2)View接口实现类
即原有的Activity和Fragment。该类中将进行Presenter接口实现类的初始化,以及Presenter相应接口的调用。
(3)Presenter接口
Presenter接口,用于定义业务逻辑。例如请求网络数据。
(4)Presenter接口实现类
用于实现Presenter定义的具体业务。此类将View接口和Modle接口作为自身的成员变量。前者由View接口实现类,在对Presenter接口实现类进行初始化时传入。而Modle接口变量,在Presenter接口实现类中进行初始化。
(5)Modle接口
Modle接口,用于定义Modle共有特性。该接口可有可无。
(6)Modle接口实现类
Modle接口的具体实现,可以理解为上例中的ServiceResponse对象。
由此可见,Presenter接口实现类是整个模式的核心部分,Modle和View在此通过接口的形式进行交互。
MVP模式,容易维护,可拆卸,可扩展,耦合性较MVC小,结构清晰。
MVP的缺点,在于开发开销相对较大。与MVC相比,需要维护更多的接口。
MVVM由三部分组成,M,V,VM,分别代表Modle,View,ViewModle。谈论MVVM模式的前提,需要了解DataBinding,即将Modle与View进行绑定,包括单向绑定(Modle影响View),双向绑定(Modle与View相互影响)。
而DataBinding的实现,需要在View中引入Modle(布局文件中加入data节点,加入数据类的引用),同样Modle中也要实现对View中控件的绑定(双向绑定时)。而这样的后果是,不仅没有将两者隔离,反而增加了耦合度。这与个人的编程习惯相抵触,因而较少使用。
MVVM模式的侧重点,在于数据和UI的联动,自动更新,而非降低耦合度。对于耦合度的问题,其实还需要结合MVP模式来解决。
Android MVP模式
Android中的MVP模式
Android MVVM模式理解
Android架构设计---关于MVVM的探讨