一、框架模式的选择

1. MVC模式

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

1.1 MVC 编程模式

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

视图（View）：负责数据展示、监听用户触摸等工作
控制器（Controller）：负责业务逻辑、事件响应、数据加工等工作
模型（Controller）：负责封装数据、存储和处理数据运算等工作

1.2 MVC通信特点

Model和View永远不能相互通信，只能通过Controller传递。
Controller可以直接与Model通信（读写调用Model），Model通过Notification和KVO机制与Controller间接通信。
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负责显示。

3.1 MVP模式的优缺点

模型与视图完全分离，我们可以修改视图而不影响模型。
可以更高效地使用模型，因为所有的交互都发生在Presenter内部。
可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。
如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑。
由于对视图的渲染放在了Presenter中，视图和Presenter的交互会过于频繁，一旦视图需要变更，Presenter也需要变更了。

3.2 MVP与MVC区别：

在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。
在MVP中view 引用Presenter ，Presenter不引用View；Presenter 引用Model，Model不引用Presenter。
在MVC里，View是可以直接访问Model的。View里会包含Model信息，不可避免的还要包括一些业务逻辑。在MVC模型里，Model不依赖于View，但是View是依赖于Model的。因为有一些业务逻辑在View里实现了，导致View的可重用性降低。
在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的新特性糅合进去，以应对客户日益复杂的需求变化。

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. 通用基础库的目录分布

【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 组价分层方式

通过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管理。

IOS工程架构，你会了吗？