关于Android框架模式的浅研究
- MVC模式
- MVP模式
- MVVM模式
- MVC、MVP、MVVM三者之间的共同点
- MVC、MVP、MVVM三者之间的区别
- 实践
- Refer
一、MVC模式
1、MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范。
2、用一种将业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。
3、MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
MVC模式图
数据关系
- View 接受用户交互请求
- View 将请求转交给Controller
- Controller 操作Model进行数据更新
- 数据更新之后,Model通知View更新数据变化
- View 更新变化数据
通信方式
- 所有方式都是单向通信
结构实现
- View :使用 Composite(组合) 模式
- View和Controller:使用 Strategy(策略) 模式
- Model和 View:使用 Observer(观察者) 模式同步信息
注意事项
1、MVC中的View是可以直接访问Model,从而,View里会包含Model信息,不可避免的还要包括一些业务逻辑。
2、在MVC模型里,Model不依赖于View,但View是依赖于Model的。
3、因为有一些业务逻辑在View里实现了,导致更改View会比较困难,至少那些业务逻辑是无法重用的。
二、MVP模式
1、MVP的全称为Model-View-Presenter,Model提供数据,View负责显示,Controller/Presenter负责逻辑的处理。
2、MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通信是通过Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是通过 Controller。
MVP模式图
数据关系
- View 接收用户交互请求
- View 将请求转交给 Presenter
- Presenter 操作Model进行数据更新
- Model 通知Presenter数据发生变化
- Presenter 更新View数据
MVP的优势
1、Model与View完全分离,修改互不影响
2、更高效地使用,因为所有的逻辑交互都发生在一个地方—Presenter内部
3、一个Preseter可用于多个View,而不需要改变Presenter的逻辑(因为View的变化总是比Model的变化频繁)。
4、更便于测试。把逻辑放在Presenter中,就可以脱离用户接口来测试逻辑(单元测试)
通信方式
- 各部分之间都是双向通信
结构实现
- View :使用 Composite模式
- View和Presenter:使用 Mediator模式
- Model和Presenter:使用 Command模式同步信息
- MVC和MVP区别
MVP与MVC最大的区别
- Model与View层之间倒底该不该通信(甚至双向通信)
MVC和MVP关系
MVP:是MVC模式的变种。
项目开发中,UI是容易变化的,且是多样的,一样的数据会有N种显示方式,业务逻辑也是比较容易变化的。
为了使得应用具有较大的弹性,我们期望将UI、逻辑(UI的逻辑和业务逻辑)和数据隔离开来,而MVP是一个很好的选择。
Presenter代替了Controller,它比Controller担当更多的任务,也更加复杂。Presenter处理事件,执行相应的逻辑,这些逻辑映射到Model和操作Model。那些处理UI如何工作的代码基本上都位于Presenter。
MVC中的Model和View使用Observer模式进行沟通;MVP中的Presenter和View则使用Mediator(中介者)模式进行通信;Presenter操作Model则使用Command(命令)模式来进行。
基本设计和MVC相同:Model存储数据,View根据Model进行表现,Presenter协调两者之间的通信。在 MVP 中 View 接收到事件,然后会将它们传递到 Presenter, 如何具体处理这些事件,将由Presenter来完成。
如果要实现的UI比较复杂,而且相关的显示逻辑还跟Model有关系,就可以在View和 Presenter之间放置一个Adapter。由这个 Adapter来访问Model和View,避免两者之间的关联。同时,因为Adapter实现了View的接口,从而可以保证View与Presenter之间接口的不变。这样就可以保证View和Presenter之间接口的简洁,又不失去UI的灵活性。
注意事项
MVP的实现会根据View的实现而有一些不同。
一部分倾向于在View中放置简单的逻辑,在Presenter放置复杂的逻辑。
另一部分倾向于在presenter中放置全部的逻辑。
这两种分别被称为:Passive View和Superivising Controller。
三、MVVM模式
MVVM是Model-View-ViewModel的简写。
微软的WPF带来了新的技术体验,如Silverlight、音频、视频、3D、动画……,这导致了软件UI层更加细节化、可定制化。
同时,在技术层面,WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。
MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。
它立足于原有MVP框架并且把WPF的新特性糅合进去,以应对客户日益复杂的需求变化。
MVVM模式图
数据关系
- View 接收用户交互请求
- View 将请求转交给ViewModel
- ViewModel 操作Model数据更新
- Model 更新完数据,通知ViewModel数据发生变化
- ViewModel 更新View数据
通信方式
- 双向绑定。View/Model的变动,自动反映在 ViewModel,反之亦然。
注意事项
- 可以兼容你当下使用的 MVC/MVP 框架。
- 增加你的应用的可测试性。
- 配合一个绑定机制效果最好。
MVVM优点
MVVM模式和MVC模式一样,主要目的是分离视图(View)和模型(Model),有几大优点:
低耦合。View可以独立于Model变化和修改,一个ViewModel可以绑定到不同的”View”上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。
可重用性。你可以把一些视图逻辑放在一个ViewModel里面,让很多view重用这段视图逻辑。
独立开发。开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计,生成xml代码。
可测试。界面素来是比较难于测试的,而现在测试可以针对ViewModel来写。
mvc,mvp,mvvm三者演化
四、MVC、MVP、MVVM三者之间的共同点
Model就是领域模型,数据对象,同时,提供外部对应用程序数据的操作的接口,也可能在数据变化时发出变更通知。Model不依赖于View的实现,只要外部程序调用Model的接口就能够实现对数据的增删改查。
View就是UI层,提供对最终用户的交互操作功能,包括UI展现代码及一些相关的界面逻辑代码。
四、MVC、MVP、MVVM三者之间的区别
三者的差异在于如何粘合View和Model,实现用户的交互操作以及变更通知
1、MVC:Controller接收View的操作事件,根据事件不同,或者调用Model的接口进行数据操作,或者进行View的跳转,从而也意味着一个Controller可以对应多个View。Controller对View的实现不太关心,只会被动地接收,Model的数据变更不通过Controller直接通知View,通常View采用观察者模式监听Model的变化。
2、MVP:Presenter,与Controller一样,接收View的命令,对Model进行操作;与Controller不同的是Presenter会反作用于View,Model的变更通知首先被Presenter获得,然后Presenter再去更新View。一个Presenter只对应于一个View。根据Presenter和View对逻辑代码分担的程度不同,这种模式又有两种情况:Passive View和Supervisor Controller。
3、MVVM:ViewModel,注意这里的“Model”指的是View的Model,跟上面那个Model不是一回事。所谓View的Model就是包含View的一些数据属性和操作的这么一个东东,这种模式的关键技术就是数据绑定(data binding),View的变化会直接影响ViewModel,ViewModel的变化或者内容也会直接体现在View上。这种模式实际上是框架替应用开发者做了一些工作,开发者只需要较少的代码就能实现比较复杂的交互。
个人的一些理解
MVP和MVVM完全隔离了Model和View,但是在有些情况下,数据从Model到ViewModel或者Presenter的拷贝开销很大,可能也会结合MVC的方式,Model直接通知View进行变更。在实际的应用中很有可能你已经在不知不觉中将几种模式融合在一起,但是为了代码的可扩展、可测试性,必须做到模块的解耦,不相关的代码不要放在一起。
在广义地谈论MVC架构时,并非指本文中严格定义的MVC,而是指的MV*,也就是视图和模型的分离,只要一个框架提供了视图和模型分离的功能,我们就可以认为它是一个MVC框架。
任何的项目框架,都是为项目服务的。没有绝对的好坏之分,只有更合适的选择。在项目进展的不同阶段,做出最合适的调整,才是是更适合团队项目发展的框架。项目设计者要谨记,任何的项目设计,都是要围绕项目发展阶段,团队成员规模,和团队整体能力而定的。切莫为了设计而设计,为了框架而框架。快速,高效的配合整个团队进展项目,才是最合适的架构。
五、实践
MVP模式的一个例子
该例子将本该是Controller(Activity)去处理的业务逻辑(登录业务)交给了Presenter去处理,简化了Activity,并且业务逻辑(登录业务员)部分可以重用。
xml文件
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">
<EditText
android:id="@+id/username_et"
android:hint="请输入账号"
android:layout_width="match_parent"
android:layout_height="wrap_content" />
<EditText
android:id="@+id/password_et"
android:hint="请输入密码"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:inputType="textPassword" />
<Button
android:id="@+id/login_btn"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="登录"/>
</LinearLayout>
IManView接口
public interface IMainView {
//如果登录成功,管家会拨打这个电话(接口)
void LoginSuccess();
//如果登录失败,管家会拨打这个电话(接口),并告诉MainActivity大妹子为什么登录失败
void LoginFailed(String msg);
}
MainActivity
public class MainActivity extends Activity implements OnClickListener, IMainView {
private static final String TAG = "MainActivity";
public static final String USERNAME = "wuzhanglao";
public static final String PASSWORD = "470782682";
private EditText username_et;
private EditText password_et;
private Button login_btn;
private MainPresenter mainPresenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
initView();
}
private void initView() {
username_et = (EditText) findViewById(R.id.username_et);
password_et = (EditText) findViewById(R.id.password_et);
login_btn = (Button) findViewById(R.id.login_btn);
login_btn.setOnClickListener(this);
//雇一个叫main的管家,然后把自己登录成功和登录失败的联系方式给他
//如果登录成功,管家会拨打loginSuccess这个电话
//如果登录失败,管家会拨打logniFailed(String msg)这个电话
mainPresenter = new MainPresenter(this);
}
@Override
public void onClick(View v) {
switch (v.getId()) {
case R.id.login_btn:
String username = username_et.getText().toString();
String password = password_et.getText().toString();
// 让自己的管家去处理登录事件
mainPresenter.login(username, password);
break;
}
}
@Override
public void LoginSuccess() {
Log.d(TAG, "管家打电话过来说:登录成功");
}
@Override
public void LoginFailed(String msg) {
Log.e(TAG, "管家打电话过来说:登录失败,失败原因:" + msg);
}
}
MainPresenter
//MainActivity的管家
public class MainPresenter {
private static final String TAG = "MainPresenter";
private IMainView view;
public MainPresenter(IMainView view) {
this.view = view;
}
// Main管家处理登录逻辑
public void login(String username, String password) {
if (username.isEmpty() || password.isEmpty()) {
view.LoginFailed("账号或密码不能为空");
} else if (username.length() < 8 || password.length() < 9) {
view.LoginFailed("账号至少8位,密码至少9位");
} else if (username.equals(MainActivity.USERNAME)) {
if (password.endsWith(MainActivity.PASSWORD)) {
// 登录成功,main拨打loginSuccess()电话通知主人登录成功了
view.LoginSuccess();
} else {
// 登录失败,main拨打loginFailed()电话通知主人登录失败了,并告知失败原因
view.LoginFailed("密码错误");
}
}
}
}