Android架构

  1. 什么是MVC，MVC的目标
  2. Android中的MVC使得acitivity既做了控制层，也做了View层，违背了单一职责原则
  3. 什么是MVP, MVP各层负责做什么，MVP的好处

MVC

MVC全称是Model-View-Controller也就是模型-视图-控制器

MVC的目的是为了将数据模型和视图分离开来，并以控制器作为连接两者的桥梁实现解耦,以使代码可扩展性、可复用性、可维护性、灵活性加强。。

MVC是一种框架模式而非应用模式。

框架面向于一系列相同行为代码的重用，设计面向的是一系列相同结构代码的重用。

平常说的架构介于框架和设计之间。

软件开发领域三种级别的重用

  • 内部重用：同一应用中能公共使用的抽象块
  • 代码重用：通用模块组合成库，以便在多个应用和领域中使用
  • 应用框架的重用：为专用领域提供通用的基础结构，获得最高级别的重用性

框架模式

框架是大智慧，用来对软件设计进行分工；设计模式是小技巧，对具体问题提出解决方案，提供代码重用率，降低耦合。

有MVC,MVVC.MVP

MVC的优点

  • 理解比较容易，开发和维护起来成本较低
  • 耦合性不高，表现层(前端)和业务层(后端)分离

MVC在Android中的实现

Acvitiy作为控制器，在Activity中获取数据和界面元素(xml布局)，将两者绑定,这里 View和Model是分离的

MVP

MVP全称Model View Presenter：

  • MVP分离表现层和逻辑层，它们之间通过接口进行通信，降低耦合。
  • 同时又带来良好的可扩展性，可测试性。
  • 理想化的MVP可以实现同一份逻辑代码搭配不同的显示界面，因为他们之间并不依赖于具体，而是依赖于抽象.

对于应用，我们需要定义分离各个层，主要是UI层，业务逻辑层和数据层.

MVP种的三个角色

  1. Presenter–交互中间人

    • Presenter主要作为沟通View和Model的桥梁，它从Model层检索数据后，返回给View层，使得View和Model之间没有耦合，也将业务逻辑从View角色上抽离出来。
    • 完成业务逻辑：业务功能逻辑，从网络获取数据逻辑

  2. View–用户界面

    View通常指Activity,Fragment或者某个View控件，它含有一个Presenter成员变量。通常View需要实现一个(展示UI的)逻辑接口，将View上的(更新OR展示UI)操作转交给Presenter进行调用，最后Presenter调用View逻辑接口将结果返回给View元素

  3. Model–数据的存取

    对于一个结构化的App来说，Model角色主要是提供数据的存取功能。Presenter需要通过Model层存储、获取数据，Model就像一个数据仓库。更直白的说，Model是封装了数据库DAO或者网络获取数据的角色，或者两种数据获取方式的集和

从网络或者数据数据库或者其他地方获取数据的逻辑过程就是业务逻辑，由Presenter持有的Model层对象引用去完成。

注：表现层(User Interface Layer)就是UI层，指的View层

2、MVP与MVC的区别（阅读时请不断对比上面的两张图）

  • Activity职责不同，Activity在MVP中是View层，在MVC中是Controller层，这是MVC和MVP很主要的一个区别，可以说Android从MVC转向MVP开发也主要是优化Activity的代码，避免Activity的代码臃肿庞大。

  • View层不同，MVC的View层指的是XML布局文件或者是用Java自定义的View，MVP的View层是Activity或者Fragment。使用传统的MVC，其中的View，对应的是各种Layout布局文件，但是这些布局文件中并不像Web端那样强大，能做的事情非常有限。MVP的View层Activity在实际项目中，随着逻辑的复杂度越来越大，Activity臃肿的缺点仍然体现出来了，因为Activity中还是充满了大量与View层无关的代码，比如各种事件的处理派发，就如MVC中的那样View层和Controller代码耦合在一起无法自拔。

  • 控制层不同，MVC的控制层是Activity，或者是Fragment，，而Activity中却又具有操作UI的功能，也做了很多View中应该做的事情，当然Activity中也包含Controller应该做的事情，比如各种事件的派发回调，而且在一层中我们会根据事件再去调用Model层操作数据，所以这种MVC的方式在实际项目中，Activity所在的Controller是非常重的，各层次之间的耦合情况也比较严重，不方便单元测试。

    MVP的控制层是Presenter，里面没有很多的实际东西，主要是做Model和View层的交互。

  • 关系链不同，MVP中Model层与View是没有关系的，彼此不会通讯和操作，Model与View的通讯都是Presenter层来传达的。但是在MVC中，Model层和View是曾在交互的。比如我们自定义的View控件里面肯定是要使用Model的数据的，View也要根据不同的Model数据做出不同的展现！这点尤其是体现在自定义的View中，自定义View需要设置数据，用户操作了自定义控件需要改变数据，View要操作Model怎么办？有人说把Controller传到自定义的View啊，现实是不可能没一个自定义View都去持有Controller的引用，其实在MVP中就不会这么尴尬，接口就可以完成。

  • 适用范围不同，在Android中，MVP和MVC都用自己的适用情况，使用MVP可以更好的解耦三大模块，模块之间比较清晰，也很方便使用MVP来组件化架构整体项目。但是MVC也是有用武之地的，在组件化的Module或者中间件我们可以使用MVC来做，Module或者中间件不会存在很复杂的View层，使用MVC可以更加方便我们实现功能。

  • 交互方式不同，MVP中通讯交互基本都是通过接口的，MVC中的通讯交互很多时候都是实打实的调用对象的方法，简单粗暴！

  • 实现方法不同 ，MVC和MVP的Model几乎一样的，都是处理数据，只要不在Activity或者Fragment中请求数据，其他的所有控制都放在Activity或者Fragment中，这样写就基本是MVC的模式，这样写不麻烦，但是很容易把Activity写出上万行代码。用MVP的时候我们需要写很多View和Presenter接口来实现模块之间的通讯，会增加很多类。
    ————————————————
    版权声明：本文为CSDN博主「Dawish_大D」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
    原文链接：https://blog.csdn.net/u010072711/article/details/77132403

背诵版

1.MVC

MVC的目的是为了将数据模型和视图分离开来，并以控制器作为连接两者的桥梁实现解耦。

MVC的M是数据，V是xml布局，控制器是activity, View 将操作反馈给 Activity，Activitiy 去获取数据，数据通过观察 者模式刷新给 View。

优点：把业务逻辑全部分离到Controller中，模块化程度高。当业务逻辑变更的时候，不需要变更View和Model，只需要Controller换成另外一个Controller就行了（Swappable Controller）。

缺点：controller测试困难。

这里activity既做了控制层，又能操作UI，随着逻辑的复杂度越来越大，activity将变得很臃肿，很难做单元测试。

2.MVP

  1. MVP全称Model View Presenter，MVP是把MVC中的Controller换成了Presenter（呈现），目的就是为了完全切断View跟Model之间的联系。presenter是什么 做什么用，view是什么，做什么用

优点：MVP分离表现层和逻辑层，它们之间通过接口进行通信，降低耦合 ，方便进行单元测试

缺点：MVP的缺点是接口爆炸，会需要写很多的接口，presenter很重

3.MVVM

他将Presenter替换成ViewModel，并通过双向数据绑定来实现视图和数据的交互。视图的数据的变化会同时修改数据源，而数据源数据的变化也会立即反应到View上。

优点：

MVVM模式它不仅解决MV耦合问题，还同时解决了维护两者映射关系的大量繁杂代码，提高开发效率。

单例模式

一个公司只有1个CEO

实现单例模式的要点

  1. 构造函数私有化

  2. 提供静态公有的getInstance()方法返回单例对象

  3. 成员变量私有化

  4. 确保单例类对象在反序列化时不会重新构建对象

几种实现方式

  1. 饿汉式

    public class public class CEO{
	public static final CEM mCEO = new CEO();
	private CEO(){}
	public static CEO getCEO(){
		return mCEO;
	}
}

  1. 懒汉式

  2. Double Check Lock 懒汉式 + volatile(防止指令重排)

动态代理

  • Mvc,mvp的差异
设计模式
设计模式

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！