Android架构(MVC、MVP和MVVM)

Android架构-----------------王坤一、概述和MVC框架模式一样，Model模型处理数据代码不变在Android的App开发中，很多人经常会头疼于App的架构如何设计：MVC、MVP和MVVM都是为了解决界面呈现和逻辑代码分离而出现的模式。经典的MVC模式是M-V-X模式的老祖宗，MVP和MVVM都是在MVC的基础上演化而来。二、MVC•M-Model:业务逻辑和实体模型(biz/bean)V-View:布局文件(XML)C-Controllor:控制器(Activity)•MVC全名是ModelViewController，如图，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。•其中M层处理数据，业务逻辑等；V层处理界面的显示结果；C层起到桥梁的作用，来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。1.MVC概述2.Android中的MVC•Android中界面部分也采用了当前比较流行的MVC框架，在Android中：•视图层(View)•一般采用XML文件进行界面的描述，这些XML可以理解为AndroidApp的View。使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改，大大增强了代码的可维护性。•控制层(Controller)•Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Actiivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。•模型层(Model)•我们针对业务模型，建立的数据结构和相关的类，就可以理解为AndroidApp的Model，Model是与View无关，而与业务相关的（感谢@Xander的讲解）。对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。3.MVC代码实例Controller控制器&ViewpublicclassMainActivityextendsActionBarActivityimplementsOnWeatherListener,View.OnClickListener{privateWeatherModelweatherModel;privateEditTextcityNOInput;privateTextViewcity;...@OverrideprotectedvoidonCreate(BundlesavedInstanceState){super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);weatherModel=newWeatherModelImpl();initView();}//初始化ViewprivatevoidinitView(){cityNOInput=findView(R.id.et_city_no);city=findView(R.id.tv_city);...findView(R.id.btn_go).setOnClickListener(this);}//显示结果publicvoiddisplayResult(Weatherweather){WeatherInfoweatherInfo=weather.getWeatherinfo();city.setText(weatherInfo.getCity());...}Controller控制器&View@Override•publicvoidonClick(Viewv){•switch(v.getId()){•caseR.id.btn_go:•weatherModel.getWeather(cityNOInput.getText().toString().trim(),this);•break;•}•}•@Override•publicvoidonSuccess(Weatherweather){•displayResult(weather);•}•@Override•publicvoidonError(){•Toast.makeText(this,获取天气信息失败,Toast.LENGTH_SHORT).show();•}•privateTfindView(intid){•return(T)findViewById(id);•}•}•从上面代码可以看到，Activity持有了WeatherModel模型的对象，当用户有点击Button交互的时候，Activity作为Controller控制层读取View视图层EditTextView的数据，然后向Model模型发起数据请求，也就是调用WeatherModel对象的方法getWeather（）方法。当Model模型处理数据结束后，通过接口OnWeatherListener通知View视图层数据处理完毕，View视图层该更新界面UI了。然后View视图层调用displayResult（）方法更新UI。至此，整个MVC框架流程就在Activity中体现出来了。Model模型•publicinterfaceWeatherModel{•voidgetWeather(StringcityNumber,OnWeatherListenerlistener);•}•................•publicclassWeatherModelImplimplementsWeatherModel{•/*这部分代码范例有问题，网络访问不应该在Model中，应该把网络访问换成从数据库读取*/•@Override•publicvoidgetWeather(StringcityNumber,finalOnWeatherListenerlistener){•/*数据层操作*/•VolleyRequest.newInstance().newGsonRequest(•Weather.class,newResponse.Listenerweather(){•@Override•publicvoidonResponse(Weatherweather){•if(weather!=null){•listener.onSuccess(weather);•}else{•listener.onError();•}•}•},newResponse.ErrorListener(){•@Override•publicvoidonErrorResponse(VolleyErrorerror){•listener.onError();•}•});•}•}•以上代码看出，这里设计了一个WeatherModel模型接口，然后实现了接口WeatherModelImpl类。controller控制器activity调用WeatherModelImpl类中的方法发起网络请求，然后通过实现OnWeatherListener接口来获得网络请求的结果通知View视图层更新UI。至此，Activity就将View视图显示和Model模型数据处理隔离开了。activity担当contronller完成了model和view之间的协调作用。MVC缺点•MVC虽然将界面呈现和逻辑代码分离了,但是在实际的Android开发中并没有完全起到想要的作用。View对应的XML文件实际能做的事情很少，很多界面显示由Controllor对应的Activity给做了，这样使得Activity变成了一个类似View和Controllor之间的一个东西。如果是小型项目，MVC是没任何问题的。因为项目比较小嘛，开发周期比较短，Controllor臃肿点也可以理解。假设项目越来越来，尤其是再加上比较复杂的逻辑，这时候一个Activity几千行代码就比较蛋疼了，再加点迷之缩进，那酸爽~~啧啧。所以MVC比较适用于快速开发的小型项目。•在Android开发中，Activity并不是一个标准的MVC模式中的Controller，它的首要职责是加载应用的布局和初始化用户界面，并接受并处理来自用户的操作请求，进而作出响应。随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。三、MVP•MVP从更早的MVC框架演变过来，与MVC有一定的相似性：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。•M-Model:业务逻辑和实体模型(biz/bean)V-View:布局文件(XML)和ActivityP-Presenter:完成View和Model的交互•MVP框架由3部分组成：View负责显示，Presenter负责逻辑处理，Model提供数据。在MVP模式里通常包含3个要素（加上Viewinterface是4个）：•View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)•Model:负责存储、检索、操纵数据(有时也实现一个Modelinterface用来降低耦合)•Presenter:作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。•*Viewinterface:需要View实现的接口，View通过Viewinterface与Presenter进行交互，降低耦合，方便进行单元测试•Tips：*Viewinterface的必要性•回想一下你在开发Android应用时是如何对代码逻辑进行单元测试的？是否每次都要将应用部署到Android模拟器或真机上，然后通过模拟用户操作进行测试？然而由于Android平台的特性，每次部署都耗费了大量的时间，这直接导致开发效率的降低。而在MVP模式中，处理复杂逻辑的Presenter是通过interface与View(Activity)进行交互的，这说明我们可以通过自定义类实现这个interface来模拟Activity的行为对Presenter进行单元测试，省去了大量的部署及测试的时间。1.什么是MVP2.MVC----MVP•两种模式的主要区别：•（最主要区别）View与Model并不直接交互，而是通过与Presenter交互来与Model间接交互。而在MVC中View可以与Model直接交互•通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑。而Controller是基于行为的，并且可以被多个View共享，Controller可以负责决定显示哪个View•Presenter与View的交互是通过接口来进行的，更有利于添加单元测试。3.MVP代码实例a.建立Bean：publicclassUserBean{privateStringmFirstName;privateStringmLastName;publicUserBean(StringfirstName,StringlastName){this.mFirstName=firstName;this.mLastName=lastName;}publicStringgetFirstName(){returnmFirstName;}publicStringgetLastName(){returnmLastName;}}3.MVP代码实例•b.建立Model•（处理业务逻辑，这里指数据读写），先写接口，后写实现•publicinterfaceIUserModel{•voidsetID(intid);•voidset