iOS：架构师之路（一）架构由来

大家好，我是OB！

在编程的世界里哪些人能成为佼佼者，取决于思考！

很多人(以前也包括我)在开发的时候，理论一直被忽视，只关注怎么实现某个功能，而并不关注为什么要这样做？这样做的好处是什么？如果能在开发中带着这两个问题去思考，我相信达成你的目标指日可待。

一、先说说为什么要设计架构？

其实在智能手机刚开始的时候，Application很简单，根本没有什么架构，一个APP就简单的几个页面。功能也非常简单，所有的逻辑都在控制器中处理了。

然后发展一段时间后，发现项目大了，业务和功能有点多了，以前一个页面只有3，4个功能，现在一个页面有十几个功能，这个时候不改变一下项目架构，那么ViewController中已经无法维护了，因为所有逻辑在一块，牵一发而动全身，维护和拓展难，架构不灵活了。

二、项目维护和拓展难，架构不灵活了怎么办？（MVC）

这个时候，MVC架构应运而生！

Model 负责业务逻辑、来自UI数据处理、本地数据、网络接收数据。
View 负责实现屏幕展示的UI、响应用户事件。
Controller 负责View与Model间的消息的转发传递。

其中View和Model之间是不通信的，只能通过controller转发信息

各个模块职责单一，各司其职，耦合度低，维护成本低，可拓展性强，可读性强
这个架构可以很好的分离各个功能的代码，复用性高，耦合度低。大家反馈不错。就这样用了较长一段时间后。新的问题来了。

每次点击View时，需要更新一下数据，这时我们要通过controller去中转，然后model收到新数据时，要更新View，也需要通过controller去中转，当这种需求多了，是不是有点麻烦？

三、View和Model通信太麻烦，怎么办？（MVVM）

既然MVC不让View和Model通信，那么我换个架构不就没有违背MVC的设计思想了。这时MVVM又应运而生了。

MVVM是由MVC转化而来。
由于Controller主要用来处理各种复杂业务逻辑，复杂的界面中Controller非常庞大，维护困难，所以有人（MVVM最初由微软提出的，大家看着办[狗头保命]）想到把Controller的逻辑处理部分抽离出来，用专门的ViewModel去管理，Controller中的代码变得非常少，变得易于测试和维护。

VM 和 View 双向绑定

MVVM 和 MVC 的区别就是 VM 和 View 是双向绑定的, 但是 Controller 和 View 不是。
MVVM借用响应式编程的思想，将view和VM数据绑定，就可以实时变更数据了，OC中有 ReactiveCocoa框架可以实现数据双向绑定，有兴趣可以研究一下ReactiveCocoa

四、模块化/组件化

如果功能继续增加，功能多到发指，几十人维护一个项目，那么单单使用以上结构都不太合适。这时结构师们又发现了模块化/组件化的设计思想。

将每个功能模块独立出去，需要时引入主项目，直接使用，既符合高内聚，低耦合，每个模块又还可以设计成MVC，MVVM…，外部只需要引入入口即可，项目目录大概这样。

架构经历了从 没有架构 -> MVC -> MVVM -> 模块化/组件化，一路走来发现所有的架构实际上都是在解决几个问题。

• 高内聚，低耦合
• 维护性好，可读性强
• 可拓展性好
• 复用性高

这就是架构的用处吧！

模块化/组件化结构设计的目的是为了解耦（满足高内聚低耦合的原则），减少模块间相互依赖，让各个模块/组件只对中间层Mediator依赖，所以不管是Target-Action还是URL Scheme方式，都是为了解耦。

Target-Action：通过NSString来实现解耦（NSString来创建对象，实现调用Action）
URL Scheme：通过在load方法中，提前注册组件，并保存到全局的routers中，通过url去匹配routers中的回调，完成模块交互