移动iOS架构分析

2020-06-16 本文已影响0人恍然如梦_b700

架构就如人体骨架，肌肉和血液还有其他就顺着骨架填充！

MVC架构思想

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

组成MVC的三个模式分别是组合模式、策咯模式、观察者模式，MVC在软件开发中发挥的威力，最终离不开这三个模式的默契配合

View层，单独实现了组合模式
Model层和View层，实现了观察者模式
View层和Controller层，实现了策咯模式

MVC要实现的目标是将软件用户界面和业务逻辑分离以使代码 可扩展性、可复用性、可维护性、灵活性加强.

image

ViewController过重

通过上面的图大家也看到了非常完美，但是用起来真有问题！
但是我们实际开发经常会变形：比如我们ViewController会非常之重，动不动几百行，几千行代码！那么是一些什么东西在里面？

繁重的网络层
复杂的UI层
难受的代理
啰嗦的业务逻辑
还有一些其他功能

image

控制器（controller）的作用就是这么简单，用来将不同的View和不同的Model组织在一起，顺便替双方传递消息，仅此而已。

这里建议：

繁重的网络层封装到我们业务逻辑管理者比如：present viewModel
复杂的UI层就应该是UI的事，直接剥离出VC

image

难受的代理就可以封装一个功能类比如我们常写的tableview collectionView的代理我们就可以抽取出来封装为一个公共模块，一些特定的逻辑就可以利用适配器设计模式，根据相应的model消息转发
image

image

耦合性问题

经常我们在开发过程中会出现下面的线！

image

这样的线对我们重用性，灵活性造成了压力
这里我推荐大家使用不直接依赖model 利用发送消息的方式传递

MVP架构思想

MVP 全称：Model-View-Presenter ；MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。

我最喜欢MVP的面向协议编程的思想！
根据产品相应的需求，写出其次需求的接口，然后根据接口去找我们响应的发起者，和接受者！面向协议编程---面向接口编程---面向需求编程---需求驱动代码！

MVP能够解决：

代码思路清晰
耦合度降低显著
通讯还算比较简单

缺点：

我们需要写很多关于代理相关的代码
视图和Presenter的交互会过于频繁
如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了

MVVM架构思想

MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑

如果要说MVVM的特色，我觉得最大莫过于：双向绑定