2.项目架构

一.架构设计的目的

   通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。
   这样做的好处是使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率，并且更容易进行后续的测试以及定位问题。
   但设计不能违背目的，对于不同量级的工程，具体架构的实现方式必然是不同的，切忌犯为了设计而设计，为了架构而架构的毛病。

二.不同架构介绍

 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