移动应用架构设计之MVC、MVP、MVVM模式应用

一、架构设计目的

  1. 通过设计使程序模块化,做到模块内部的高聚合和模块之间的低耦合
  2. 提高开发效率,便于测试及问题定位
  3. 提高可维护性、可扩展性

二、三层架构模型

一般而言,软件的开发可分为三层架构:界面层(User Interface layer, UIL)、数据访问层(Data access layer, DAL)、业务逻辑层(Business Logic Layer, BLL)。

  1. 界面层:主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。
  2. 数据访问层:与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层,同时将业务层处理的数据保存到数据库。
  3. 业务逻辑层:UI层和DA层之间的桥梁。实现业务逻辑。业务逻辑具体包含:验证、计算、业务规则等等。如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。

1.1、 分层规则

  1. UI层只能作为一个外壳,不能包含任何业务逻辑处理过程。只有少量(或者没有)SQL语句或者存储过程的调用,并且这些语句保证不会修改数据。
  2. 设计时应该从BLL出发,而不是UI出发。BLL层在API上应该实现所有负责的业务处理过程(以面向对象的方式)。如果把UILayer拿掉,项目还能在Interface/API的层次上提供所有功能)。

1.2、 优势

  1. 结构清晰、耦合度低。
  2. 可维护性高,可扩展性高。
  3. 利于开发任务同步进行,容易适应需求变化。

1.3、 劣势

  1. 有时会导致级联修改。这种修改尤其体现在自上而下的方向,如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
  2. 增加了代码量,增加了工作量。

三、 MVC框架

1、框架示意图

移动应用架构设计之MVC、MVP、MVVM模式应用_第1张图片

2、请求流程

  1. View接受用户的请求
  2. View传递请求给Controller
  3. Controller操作Model进行数据更新
  4. Model通知View变化
  5. View根据更新的数据做出显示

3、程序实例

小明需要开发一个功能,当点击“find student id”按钮时,可以查询到他自己的学号。

对于MVC 实现,应该是这样的:

1、先实现一个 model,需要有通知View更新的能力,当model加载成功,如从db、获取后,需要告知View:

public class StudentModel {

    String mId;
    WelcomeActivity mActivity;

    public StudentModel (WelcomeActivity activity) {
        this.mActivity = activity;
    }
    public void loadModel (){
        //search from db or intent
        mId = "1201030018";
        mActivity.updateUI(this);
    }

}

2、Controller : 我们为了更好的理解MVC,将Activity进行了拆解。提取了一个简单的Controller

public class WelcomeController {

    WelcomeActivity mActivity;
    StudentModel mStudent;

    WelcomeController (WelcomeActivity activity) {
        this.mActivity = activity;
    }

    public void loadData (){
        mStudent = new StudentModel(mActivity);
        mStudent.loadModel();
    }
}

3、View : View需要发出点击事件,并且传递给Controller,同时需要根据Model更新UI:

public class WelcomeActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
       //省略
        final WelcomeController controller = new WelcomeController(this);
        mFindBtn.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                controller.loadData();
            }
        });
    }

    public void updateUI (StudentModel model) {
        mID.setText(model.mId);
    }
}

调用链是:
View:OnClick ->
Controller:loadData->
Model:loadModel->
View:updateUI

Tips:为了更明显的表明意图,将Activity单纯的看做一个View。

4、优缺点

1、优点:

  • 把业务逻辑全部分离到Controller中,模块化程度高。当业务逻辑变更的时候,不需要变更View和Model,只需要Controller换成另外一个Controller就行了(Swappable Controller)。
  • 观察者模式可以做到多视图同时更新

2、缺点:

  • Controller测试困难。因为视图同步操作是由View自己执行,而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候,Controller业务逻辑的正确性是无法验证的:Controller更新Model的时候,无法对View的更新操作进行断言。
  • View无法组件化。View是强依赖特定的Model的,如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的。

四、MVP框架

1、框架示意图

移动应用架构设计之MVC、MVP、MVVM模式应用_第2张图片

2、请求流程

  1. View 接受用户请求
  2. View 传递请求给Presenter
  3. Presenter做逻辑处理,修改Model
  4. Model 通知Presenter数据变化
  5. Presenter 更新View

相比于MVC,MVP则使用Presenter解除了View与Model的耦合Presenter将Model的变化返回给View

3、程序实例

同样的例子,我们使用MVP进行改写

1、我们需要先对Model进行封装,当loadModel后,不直接通知View更新,而是通知监听方(Presenter):

public class StudentModel {
    String mId;
    OnGetListener mListener;

    public StudentModel (OnGetListener listener) {
        this.mListener = listener;
    }
    public void loadModel (){
        //search from db or intent
        mId = "1201030018";
        if (mListener != null) {
            mListener.onSuccess(this);
        }
    }
    interface OnGetListener {
        void onSuccess (StudentModel student);
    }
}

2、再定义Presenter ,接收到来自View的操作命令后,进行逻辑处理,处理Model,修改完成后 通知View进行修改。

public class WelcomePresenter {

    WelcomeActivity mActivity;
    StudentModel mStudent;

    WelcomePresenter (WelcomeActivity activity) {
        this.mActivity = activity;
    }

    public void loadData (){
        mStudent = new StudentModel(new StudentModel.OnGetListener() {
            @Override
            public void onSuccess(StudentModel student) {
                mActivity.updateUI(student);
            }
        });
    }
}

3、对于View,操作方式只是修改了持有的对象 WelcomeController->WelcomePresenter,其他保持不变。

这时调用流程变成了:

View:OnClick ->
Presenter:loadData->
Model:loadModel->
Presenter:onSuccess>
View:updateUI

我们将View的数据更新 从Model->View,转变成了Presenter->View,解除了View和Model的耦合。

4、优缺点

1、优点:

  • 便于测试。Presenter对View是通过接口进行,在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象,这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中,单元测试的时候就可以完整的测试Presenter业务逻辑的正确性。
  • View可以进行组件化。在MVP当中,View不依赖Model。这样就可以让View从特定的业务场景中脱离出来,可以说View可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做高度可复用的View组件。

2、缺点:

  • Presenter中除了业务逻辑以外,还有大量的View->Model,Model->View的手动同步逻辑,造成Presenter比较笨重,维护成本高

五、MVVM框架

1、框架示意图

移动应用架构设计之MVC、MVP、MVVM模式应用_第3张图片

2、请求流程

在Android 借助Google提出的 DataBinding 框架完成 双向绑定操作。在MVVM框架中,除了将 Presenter 换成了 ViewModel 外,请求流程都和MVP类似,只是在最后一步中,由于View与ViewModel使用了双向绑定,两者的交互通过Data Binding 完成。如此使得View和控制模块的耦合更加降低,减轻了视图的压力

3、程序实例

同样的例子,我们引入Data Binding解决这个问题。

1、把Controller\Presenter扔掉,先写一个ViewModel。

这个VM的概念是一个和视图相关的模型,因此可以和DAO相关的模型不一样,因为我们只需要展示student id的数据以及click事件,以及loadData行为,用来从Model中获取数据,于是我们实现了一个VM :(这里我们需要遵循Data Binding的语法,如继承自BaseObservable,数据更新后调用notifyChange方法等。)

public class StudentViewModel extends BaseObservable{

    String studentID;
    View.OnClickListener btnListener;
   //省略get set

    public StudentViewModel() {
        btnListener = new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                loadData();
            }
        };
    }

    public void loadData() {
        StudentModel model = new StudentModel(new StudentModel.OnGetListener() {
            @Override
            public void onSuccess(StudentModel student) {
                setStudentID(student.mId);
            }
        });
        model.loadModel();
    }
}

2、接着使用databinding语法 对 xml 进行数据绑定,我们将 Click事件、输出结果都绑定到VM上。



    
        
    
    
          

3、最后在View(Activity)中引入VM :

public class WelcomeActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
       
        ActivityWelcomeBinding binding = DataBindingUtil.setContentView(this,R.layout.activity_welcome);

        final StudentViewModel studentViewModel = new StudentViewModel();
        binding.setUserVM(studentViewModel);
    }

}

这样就完成了最基本的MVVM 栗子。现在我们的Activity看起来很清爽,不用再处理Click事件、以及updateUI了。

4、优缺点

1、优点

  • 低耦合。视图(View)可以独立于Model变化和修改,一个ViewModel可以绑定到不同的”View”上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。
  • 提高可维护性。解决了MVP大量的手动View和Model同步的问题,提供双向绑定机制。提高了代码的可维护性。
  • 简化测试。因为同步逻辑是交由Binder做的,View跟着Model同时变更,所以只需要保证Model的正确性,View就正确。大大减少了对View同步更新的测试。

2、缺点

  • 过于简单的图形界面不适用,或说牛刀杀鸡。
  • 对于大型的图形应用程序,视图状态较多,ViewModel的构建和维护的成本都会比较高。
  • 数据绑定的声明是指令式地写在View的模版当中的,这些内容是无法进行断点调试的。

六、总结

各种MV+X模式的发展,实质上就是将Model与View之间以一种低耦合、低成本的方式进行控制。MVC中模型和视图没有完全分离,造成Activity代码臃肿,MVP中通过Presenter来进行中转,模型和视图彻底分离,但由于V和P互相引用,代码不够优雅。ViewModel通过Data Binding实现了视图和数据的绑定,解决了这种MVP的缺陷,但目前也存在Data Binding还不成熟的问题。

从Presenter到ViewModel的转变,借助了Data Binding的方式实现了双向的数据绑定,减少了视图模块和控制模块的耦合。随着Google Data Binding技术的不断更新完善,相信MVVM模式将在Android平台下应用得更加广泛。

 

 

参考:

https://www.jianshu.com/p/9df92995ee26

 

你可能感兴趣的:(【Android应用层】)