iOS架构设计

1、MVC

1、Model 和 View 永远不能相互通信，只能通过 Controller 传递。
2、Controller 可以直接与 Model 对话（读写调用 Model），Model 通过 Notification 和 KVO 机制与 Controller 间接通信。
3、Controller 可以直接与 View 对话，通过 outlet，直接操作 View，outlet 直接对应到 View 中的控件，View 通过 action 向 Controller 报告事件的发生(如用户 Touch 我了)。Controller 是 View 的直接数据源（数据很可能是 Controller 从 Model 中取得并经过加工了）。Controller 是 View 的代理（delegate)，以同步 View 与 Controller。

2、MVP
MVP模式是MVC模式的一个演化版本,MVP全称Model-View-Presenter

1、Model 层应该不仅仅是创建一个数据对象，还应该包含网络请求，以及数据 SQLite 的 CRUD 操作（比如 iOS 平台，一般以 FMDB 框架直接操作 sql，或者用 CoreData) 。一般可以将数据对象是否需要缓存设计成一个字段 isCache，或者针对整个项目设计一个开存储关，决定整个项目是否需要数据缓存。我们常见的新闻类 App，在离线的时候看到的数据，都是做了缓存处理的。比如一些金融类的 App，实时性比较高，是不做缓存的。2、View 层比较简单明，就是 View 的一些封装、重用。在一款精心设计过的 App 里面，应该有很多 View 是可以封装重用的。比如一些自己的 TableViewCell，自己设计的 Button，一些 View（包含一些子 View，UI 精心设计过，在项目里多处出现的）等等。3、Presenter 层并不涉及数据对象的网络请求和 SQLite 操作，只是 Model 层和 View 层的一个桥梁。Presenter 层就不至于太臃肿，容易看懂。一些大的 App，或因为上线时间比较久了，经历过众多程序员的修补，或因前期并未做好架构，以至于打开一个类，几千行的代码，看着自己都晕。

优势：模型与视图完全分离，我们可以修改视图而不影响模型可以更高效地使用模型，因为所以的交互都发生在一个地方——Presenter内部我们可以将一个Presener用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

3、MVVM
MVVM是Model-View-ViewModel的简写，而View包括view层和viewcontroller层，是MVC 的改进版，主要是将视图 UI 和业务逻辑分开，ViewModel负责取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑

1.在 MVVM 里，view 和 view controller 正式联系在一起，我们把它们视为一个组件。视图 view 仍然不能直接引用模型 Model，当然 controller 也不能。相反，他们引用视图模型 View Model。
2.View Model 是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其他各种各样的代码的极好的地方。有一件事情不应归入 View Model，那就是任何视图本身的引用。View Model 的概念同时适用于于 iOS 和 OS X（换句话说，不要在 View Model 中使用 #import UIKit.h）。3.由于展示逻辑（presentation logic）放在了 View Model 中（比如 Model 的值映射到一个格式化的字符串），视图控制器本身就会不再臃肿。当然你开始使用 MVVM 的最好方式时可以先将一小部分逻辑放入视图模型，然后当你逐渐习惯于使用这个范式的时候再迁移更多的逻辑到视图模型中。