一.架构设计的目的
通过设计使程序模块化,做到模块内部的高聚合和模块之间的低耦合。
这样做的好处是使得程序在开发的过程中,开发人员只需要专注于一点,提高程序开发的效率,并且更容易进行后续的测试以及定位问题。
但设计不能违背目的,对于不同量级的工程,具体架构的实现方式必然是不同的,切忌犯为了设计而设计,为了架构而架构的毛病。
二.不同架构介绍
1.MVC
1>.层次:
Model: 模型(用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法)
View: 视图(渲染页面)
Controller: 控制器(M和V之间的连接器,用于控制应用程序的流程,及页面的业务逻辑)
特点:应用程序中的数据模型与业务和展示逻辑解耦.就是将模型(M-数据、操作数据)、视图(V-显示数据的HTML元素)之间实现代码分离,松散耦合,使之成为一个更容易开发、维护和测试的客户端应用程序。
2>.优点:
耦合性低,视图层和业务层分离,这样就允许更改视图层代码而不用重新编译模型和控制器代码。
重用性高
MVC使开发和维护用户接口的技术含量降低
可维护性高,分离视图层和业务逻辑层也使得WEB应用更易于维护和修改,部署快.
3>.缺点:
不适合小型,中等规模的应用程序,花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
视图与控制器间过于紧密连接,视图与控制器是相互分离,但却是联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用。
视图对模型数据的低效率访问,依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也将损害操作性能。
4>.应用:
在web app 流行之初, MVC 就应用在了java(struts2)和C#(ASP.NET)服务端应用中,后来在客户端应用程序中,基于MVC模式,AngularJS应运而生。
2.MVP
1>.层次:
Model: 模型(用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法)
View: 视图(渲染页面)
Presenter负责业务逻辑:
2>.特点:M、V、P之间双向通信。
View 与 Model 不通信,都通过 Presenter 传递。
Presenter完全把Model和View进行了分离,主要的程序逻辑在Presenter里实现。
View 非常薄,不部署任何业务逻辑,称为”被动视图”(Passive View),即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。
Presenter与具体的View是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更View时候可以保持Presenter的不变,这样就可以重用。不仅如此,还可以编写测试用的View,模拟用户的各种操作,从而实现对Presenter的测试–从而不需要使用自动化的测试工具。
3>.优点:
模型与视图完全分离,我们可以修改视图而不影响模型;
可以更高效地使用模型,因为所有的交互都发生在一个地方——Presenter内部;
我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁;
如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)。
4>.缺点:
不适合小型,中等规模的应用程序,花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
视图和Presenter的交互会过于频繁,使得他们的联系过于紧密。也就是说,一旦视图变更了,presenter也要变更。
5>.应用:
由于前期部署耗费时间,不适用与小型项目.
3.MVVM
1>.层次:
Model: 模型(用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法)
View: 视图(渲染页面)
ViewModel负责业务逻辑:
2>.优点:
主要目的是分离视图(View)和模型(Model)
低耦合,视图(View)可以独立于Model变化和修改,一个ViewModel可以绑定到不同的”View”上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。
可重用性,可以把一些视图逻辑放在一个ViewModel里面,让很多view重用这段视图逻辑。
独立开发,开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计,使用Expression Blend可以很容易设计界面并生成xml代码。
可测试,界面向来是比较难于测试的,而现在测试可以针对ViewModel来写。
3>.缺点:
类会增多每个VC都附带一个viewModel,类的数量*2viewModel会越来越庞大我们把逻辑给了viewModel,那势必Model也会变得很复杂,里面的属性和方法越来越多。可能重写的方法比较多,因为涉及到一些数据的转换以及和controller之间的通信。
调用复杂度增加
由于数据都是从viewModel来,想想突然来了一个新人,一看代码,不知道真实的模型是谁。比如常用tableview的数据源,一般都是一个数组,如果不断的通过viewModel去取,沟通上没有那么直接。况且每封一层,意味着要写很多代码去融合他们的转换。
4>.应用:
目前使用的较少
三.举例MVP
1.因为每一个刚进入IT界的小白大多都是要从MVC架构开始学起的,又因为它太耦合度太高,我们不太常用了,但是还是有人用的,逻辑简单.所以这里就不详细的介绍它了.
2.而对于MVVM而言,应为太过于解耦,比如说在公司里交接项目的时候,如果前面的人不详细的介绍清楚每个类在哪里用过等等,会让后者摸不着头脑,非常不容易下手.所以,也不再多做介绍了.
3.那么我们就从MVP开始吧:
1.以MVP架构结合Retrofit和Rxjava为例:
1.首先附上依赖,也可以去官网上搜,本文中的依赖是2.x版本的
//网络框架
//注意 使用最新的依赖 导包的时候,导的是io包下的观察者和订阅者
//1.它会自动引用基础库与Android库
implementation 'com.trello.rxlifecycle2:rxlifecycle-components:2.1.0'
//2.注意使用线程调度器时,在网络请求工具类中使用的Rxjava+Retrofit的依赖是最新的2.x.y,可以去GitHub中去查找最新的:
//retrofit and rxjava
implementation 'com.squareup.retrofit2:retrofit:2.4.0'
implementation 'com.squareup.retrofit2:converter-gson:2.4.0'
implementation 'com.jakewharton.retrofit:retrofit2-rxjava2-adapter:1.0.0'
implementation 'io.reactivex.rxjava2:rxandroid:2.1.0'
//3 日志拦截器
//1 如果使用OKHttp了,就将以前的依赖使用下面的依赖替换掉,下面的依赖会自带拦截器:
implementation 'com.squareup.okhttp3:logging-intercept