IOS工程架构,你会了吗?

·  阅读 1614

一、框架模式的选择

1. MVC模式

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

1.1 MVC 编程模式

MVC 是一种使用 MVC(Model View Controller 模型-视图-控制器)设计应用程序的模式

  • 视图(View):负责数据展示、监听用户触摸等工作

  • 控制器(Controller):负责业务逻辑、事件响应、数据加工等工作

  • 模型(Controller):负责封装数据、存储和处理数据运算等工作

1.2 MVC通信特点

2021051517090759.png

  1. Model和View永远不能相互通信,只能通过Controller传递。

  2. Controller可以直接与Model通信(读写调用Model),Model通过Notification和KVO机制与Controller间接通信。

  3. Controller与View通过Target/Action,delegate和datasource三种模式进行通信。

通过这三种模式,View就可以向Controller通信,Action/Target 模式来让Controller 监听View 触发的事件。View又通过Data source和delegate进行数据获取和某些通信操作。

1.3 MVC优缺点

1. 易用性:与其他几种模式相比最小的代码量,维护起来也较为容易。

2. 可测性:由于糟糕的分散性,只能对Model进行测试。

3. 均衡性:厚重的ViewController、无处安放的网络逻辑与数据逻辑。

2.MVCS模式

苹果自身就采用的是这种架构思路,从名字也能看出,也是基于MVC衍生出来的一套架构。从概念上来说,它拆分的部分是Model部分,拆出来一个Store。这个Store专门负责数据存取。

从实际操作的角度上讲,它拆开的是Controller。因为Controller做了数据存储的事情,就会变得非常庞大,那么就把Controller专门负责存取数据的那部分抽离出来,交给另一个对象去做,这个对象就是Store。这么调整之后,整个结构也就变成了真正意义上的MVCS。

  • 视图(View):用户界面

  • 控制器(Controller):业务逻辑及处理

  • 模型(Model):数据存储

  • 存储器(Store):数据处理逻辑

MVCS是基于瘦Model的一种架构思路,把原本Model要做的很多事情中的其中一部分关于数据存储的代码抽象成了Store,在一定程度上降低了Controller的压力。

3. MVP模式

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

0af902ea9926b6ed803a1f521c59bb3f.webp

3.1 MVP模式的优缺点

  1. 模型与视图完全分离,我们可以修改视图而不影响模型。

  2. 可以更高效地使用模型,因为所有的交互都发生在Presenter内部。

  3. 可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。

  4. 如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑。

  5. 由于对视图的渲染放在了Presenter中,视图和Presenter的交互会过于频繁,一旦视图需要变更,Presenter也需要变更了。

3.2 MVP与MVC区别:

  1. 在MVP中View并不直接使用Model,它们之间的通信是通过Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是通过 Controller。

  2. 在MVP中view 引用Presenter ,Presenter不引用View;Presenter 引用Model,Model不引用Presenter。

  3. 在MVC里,View是可以直接访问Model的。View里会包含Model信息,不可避免的还要包括一些业务逻辑。 在MVC模型里,Model不依赖于View,但是View是依赖于Model的。因为有一些业务逻辑在View里实现了,导致View的可重用性降低。

  4. 在MVC里,不建议在 View 中依赖 Model,而是尽可能把业务逻辑都放在 Controller 中处理,使View 只和 Controller 交互。

4.MVVM模式

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

MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去,以应对客户日益复杂的需求变化。

20210515171017267.png

4.1 MVVM模式的组成部分

  • 模型:模型是指代表真实状态内容的领域模型(面向对象),或指代表内容的数据访问层(以数据为中心)。

  • 视图:就像在MVC和MVP模式中一样,视图是用户在屏幕上看到的结构、布局和外观(UI)。

  • 视图模型:视图模型是暴露公共属性和命令的视图的抽象。在视图模型中,绑定器在视图和数据绑定器之间进行通信。

引用特点:view 引用viewModel ,viewModel不引用view(即不要在viewModel中引入#import UIKit.h,任何视图本身的引用都不应该放在viewModel中);viewModel 引用model,model不引用viewModel。

3.2 MVVM优点

  • 低耦合:View可以独立于Model变化和修改,一个ViewModel可以绑定到不同的View上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。

  • 可重用性:你可以把一些视图逻辑放在一个ViewModel里面,让很多view重用这段视图逻辑。

  • 独立开发:开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计。

  • 可测试:界面素来是比较难于测试的,而现在测试可以针对ViewModel来写。

3.2 MVVM与MVP区别:

mvvm模式将Presener改名为View Model,基本上与MVP模式完全一致,唯一的区别是,MVVM可以结合RAC(MVVM+RAC)实现view与ViewModel的双向绑定,这样开发者就不用处理接收事件和View更新的工作。

二、通用基础库与cocoaPod应用

1. 通用基础库的目录分布

20210518160007185.png

【Service】业务服务层,存放公共业务逻辑与通用服务,如公共接口、基础组件配置、用户信息、共享数据、页面路由配置等。

【BaseKit】基础层,存放着通用的基础库,应用于各个业务模块。

CommonLib:通用功能组件,具体功能的实现和应用,如APM、数据上报、页面路由、OCR等。

Views:通用视图组件,如BannerView、AlertView、pageControl、loadingView等。

Kernal:基础服务组件,提供基础服务能力,如Network、Log、dataBase、webImage等。

Basic:基础类,又分为MVC三个子目录,封装存放Basic类。

Marco:通用声明,宏定义-define、常量声明-extern。

Utils:工具类集合,如Tools、Authoritys、Encrypt、NetworkAccessible等 。

Categorys:公共类别扩展,可按照类属性的不同分为不同的子目录,如View、Datas、Image等。

备注:自上而下的依赖关系

2. cocoaPod应用

cocoaPod应用IOS开发者应该都比较熟悉,主要是用关联第三方库与私有组件库,方便版本迭代管理。

2.1 GitHub第三方库

CocoaPods详解之-使用篇:blog.csdn.net/meegomeego/…

2.2 GitLab私有库

CocoaPod-spec私有库配置:blog.csdn.net/z119901214/…

三、业务组件&组件通讯

1. 业务组件

业务组件主要是指作为一个大的业务模块,单独分离成一个组件的形式,如电商模块、聊天模块、博客等。业务组件之间不存在耦合代码,由组件通讯中间层实现彼此的通讯。

1.1 组价分层方式

20210224000103415.png

通过xcworkspace的方式分层,A为主工程,B、C为两个业务模块 目录分层:在主业务目录下,按照不同的业务组件创建不同的目录,业务模块独立,组件之间不直接调用API。

xcworkspace分层:通过xcworkspace的方式,不同的业务模块创建各自的project工程,业务project工程run成功后,将framework引入主工程中。

pod组件分层:以pod-specs的方式引入业务组件,各个业务模块都独立成一个工程,具体可以参考github组件化项目-iOS-Component-Pro

1.2 组件分层方式的特点

  • 目录分层:目录分层比较简单,没有实现真正的代码分割,所以目录与目录直接的类是可以引用的,这样就很依赖于团队开发的规范性。

  • xcworkspace分层:xcworkspace分层实现了不同业务组件代码的分割,作为framework的形式引入。动态编译的形式引入会影响到编译打包的效率;打包成静态framework的形式引入更新迭代成本比较高,而且不利于cocoaPod的使用。

  • pod组件分层:实现了不同业务组件代码的分割,又解决了xcworkspace分层影响编译效率与不利于cocoaPod使用的问题,业务组件与基础组件统一使用cocoaPod管理。

版权声明:本文为CSDN博主「い红尘ぅ秋枫」的原创文章。原文链接blog.csdn.net/z119901214/…
分类:
iOS
标签: