当前位置:网站首页>软件架构之--MVC、MVP、MVVM

软件架构之--MVC、MVP、MVVM

2022-08-11 05:22:00 骑猪追大象

MVC

简介

MVC全名是Model View Controller,是 模型(model)-视图(view)-控制器(controller) 的缩写,用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。
在很长的一段时间MVC被用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。在Android中,Activity的角色宽泛的说就是Controller(实际上在MVC中很难区分Activity到底应该处于V还是C的角色,因为activity即包含了界面也包含了一部分逻辑处理),xml布局就是 View 层的表现,而网络请求的数据或者数据库表现为 Model 层。

简单概括就是:

项目说明
View(视图层)用户界面
Controller(控制层)业务逻辑
Model(数据层)数据保存

图示关系

下图表达出了三者之间的关系:
MVCView 传送指令到 Controller
Controller 完成业务逻辑后,要求 Model 改变状态
Model 将新的数据发送到 View,用户得到反馈

可以看到,在MVC模型里,Model不依赖于View,但是View是依赖于Model,这就避免不了我们会在View里面有业务逻辑,当复用和扩展的时候由于有业务逻辑的参与,改动变得困难,比方说我们经常在点击事件中处理网络访问,将拿到的数据在更新UI,就会发现界面展示层做的东西除了自身UI外还有其他自己不应该关心的事情。我们始终的宗旨是:各司其职,互相隔离。

//View和Model耦合举例
public class MainActivity extends AppCompatActivity {
    

    @Override
    protected void onCreate(Bundle savedInstanceState) {
    
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        
        findViewById(R.id.main_btn).setOnClickListener(new View.OnClickListener() {
    
            @Override
            public void onClick(View v) {
    
               //1.接口请求数据
               //2.更新UI
            }
        });
    }


}

优缺点

优点

  1. 耦合度较低
    视图层和业务层分离,这样就允许更改视图层代码而不用重新编译模型和控制器代码,同样,一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离,所以很容易改变应用程序的数据层和业务规则。1
  2. 重用度高
    MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码,因为多个视图能共享一个模型,它包括任何WEB(HTTP)浏览器或者无线浏览器(wap),比如,用户可以通过电脑也可通过手机来订购某样产品,虽然订购的方式不一样,但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化,所以同样的构件能被不同的界面使用。例如,很多数据可能用HTML来表示,但是也有可能用WAP来表示,而这些表示所需要的命令是改变视图层的实现方式,而控制层和模型层无需做任何改变。由于已经将数据和业务规则从表示层分开,所以可以最大化的重用代码了。模型也有状态管理和数据持久性处理的功能,例如,基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。1
  3. 成本低
    MVC使开发和维护用户接口的技术含量降低。1
  4. 部署快
    使用MVC模式使开发时间得到相当大的缩减,它使程序员(Java开发人员)集中精力于业务逻辑,界面程序员(HTML和JSP开发人员)集中精力于表现形式上。 1

缺点

  1. 没有明确的定义
    完全理解MVC并不是很容易。使用MVC需要精心的计划,由于它的内部原理比较复杂,所以需要花费一些时间去思考。同时由于模型和视图要严格的分离,这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。1
  2. 增加系统结构和实现的复杂性
    对于简单的界面,严格遵循MVC,使模型、视图与控制器分离,会增加结构的复杂性,并可能产生过多的更新操作,降低运行效率。难以测试,必须手动点击,使用各种自动化的测试工具。1
  3. 视图与控制器间的过于紧密的连接
    视图与控制器是相互分离,但却是联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用。1
  4. 视图对模型数据的低效率访问
    依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也将损害操作性能。1
  5. 一般高级的界面工具或构造器不支持模式
    改造这些工具以适应MVC需要和建立分离的部件的代价是很高的,会造成MVC使用的困难。1
  6. 代码难以重用。
    UI是很难重用,因为要求总是不同。所以,导致重复的代码四处都是,维护麻烦。

应用场景

交互简单的小型应用程序

MVP

简介

MVP(Model View Presenter)则是对MVC的进一步改造,MVP的出现就是为进一步分离业务逻辑和界面处理。在MVP中,M与V完全切断联系,由P进行总控。当V接收到了操作,将相应的请求传递到P,由P进行业务处理以及与M进行交互,同时P又在恰当的时机对view进行更新(接口 / 回调方法 / 事件)。这样V只需要暴露出接口,V与P通过接口通讯,一方面能够将业务逻辑转移至P,一方面通过接口使得P可以适配多个V。

图示关系

在这里插入图片描述
在MVP里,Presenter完全把Model和View进行了分离,主要的程序逻辑在 Presenter里实现。而且,Presenter与具体的View是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更View时候可以保持Presenter的不变,即重用!

不仅如此,我们还可以编写测试用的View,模拟用户的各种操作,从而实现对Presenter的测试–而不需要使用自动化的测试工具。

我们甚至可以在Model和View都没有完成时候,就可以通过编写Mock Object(即实现了Model和View的接口,但没有具体的内容的)来测试Presenter的逻辑。

在MVP里,应用程序的逻辑主要在Presenter来实现,其中的View是很薄的一层。 因此就有人提出了Presenter First的设计模式,就是根据User Story来首先设计和开发Presenter。在这个过程中,View是很简单的,能够把信息显示清楚就可以了。在后面,根据需要再随便更改View, 而对Presenter没有任何的影响了。

如果要实现的UI比较复杂,而且相关的显示逻辑还跟Model有关系,就可以在View和 Presenter之间放置一个Adapter。由这个 Adapter来访问Model和View,避免两者之间的关联。而同时,因为Adapter实现了View的接口,从而可以保证与Presenter之 间接口的不变。这样就可以保证View和Presenter之间接口的简洁,又不失去UI的灵活性。 2

总结如下

1. Presenter完全将Model和View解耦,主要逻辑处于Presenter中。
2. Presenter和具体View没有直接关联,通过定义好的接口进行交互。
3. View变更时,可以保持Presenter不变(符合面向对象编程的特点)
4. View只应该有简单的Set/Get方法、用户输入、界面展示的内容,此外没有更多内容。
5. 低耦合:Model和View的解耦,决定了该特性。

在MVP模式里,View只应该有简单的Set/Get的方法,用户用户输入和设置界面显示的内容,除此就不应该有更多的内容,绝不容许直接直接访问Model–这就是与MVC很大的不同之处。

优缺点

优点

  1. 模型与视图完全分离,修改视图完全不影响模型 1
  2. 可以更高效地使用模型,因为所有的交互都发生在一个地方——Presenter内部
  3. 我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁。
  4. 如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)

缺点

由于对视图的渲染放在了Presenter中,所以视图和Presenter的交互会过于频繁。还有一点需要明白,如果Presenter过多地渲染了视图,往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更,那么Presenter也需要变更了。比如说,原本用来呈现Html的Presenter现在也需要用于呈现Pdf了,那么视图很有可能也需要变更;代码量会增加,针对简单的业务逻辑也需要创建对应M、V、P层;

应用场景

虽然代码量会很大,但是代码结构清晰明了,可读性强,适用于中大型应用软件,前期可能觉得比较繁琐,后期维护起来就变得异常简单了。

Demo

这个是简单的例子:
采用了泛型优化MVP的类文件量
MVP demo

MVVM


  1. https://www.jianshu.com/p/ff6de219f988.html

  2. https://www.cnblogs.com/xianshui/p/8469158.html

原网站

版权声明
本文为[骑猪追大象]所创,转载请带上原文链接,感谢
https://blog.csdn.net/luzhenyuxfcy/article/details/106014704