Do MVC like it’s 1979
文章内容：链接
文章讲了1979年最开始提出 MVC概念时的观点和现在 iOS 流行的 MVC 对比
controller or editor
在最开始，controller 应该被称为 editor，负责去update view，到了后面才被称为 controller
流程改变
最早的MVC 架构如上，可见违反了一些我们共同认知的软件设计原则：
- Single responsibility单一原则。controller 和 view 都能去改变 model
- Loose coupling and high cohesion 松耦合和高内聚。由于model 依赖于 view 和 controller，所以如果修改接口，会影响其他的实体。
所以，最早的的MVC 模型是不适用的。
apple 提出的 MVC 模型如下
可见，apple 的 mvc 模型会导致大量的逻辑堆积在一个实体上，比如 controller。多数用户没能很好应用 model 去承载业务逻辑。
从 MVC 设计中学习
不把 MVC 仅当做一个架构，作为一种设计理念，可以学习到以下内容
分离。
MVC 定义了三个组件来承担逻辑。
Facade。（外观模式）
通常开发忽略了在 model中处理共用逻辑，而全部放在了 controller 中。因此造成了胖 controller 和 瘦 model 。facade 意味这一个对象隐藏了大量的逻辑实现。避免直接和 model 进行沟通。外观模式保证了 model 在增长的过程中不影响上层。
观察者
观察者是一种通用的来对 model 解耦的方法。通常的做法是，model 不关心谁需要知道状态变更，而是发出状态变更的通知。相关观察了 model 的实体会去接收通知，执行对应的逻辑。
通过观察者模式，可以讲 model layer设计成独立的服务。服务的生命周期等同于应用的声明周期。如网络服务，统计服务，聊天服务。
Mediator(传递者）
在 MVC中，controller 承担着 mediator 的责任。一个对象，依赖越多，承担的逻辑应该越少（这里应该认为，如果承担过多的逻辑，修改的成本很高）
controller 因此会承担很多浇水代码。
因为 controller 的胶水属性，尽可能避免在 controller 中保存状态值，以 model 的 computer interface 来计算出来
现代工程的 MVC
APPLE MVC
常见的 iOS 架构设计，苹果经典的 MVC。
viewController 同时担任了 view 和 controller的职责
缺点 controller 臃肿
MVP/MVVM
强调了单一原则。
VIPER/Riblets
和 MVX 的不同在于改变了形态，使用 Service/Repository/Storage
至少有两个 controller ，分别为 router(路由)，presenter(展示器)
学到了什么
- 不要把 MVC 仅仅当做一种架构，而是一种架构设计的思想
- 不仅仅能解释一种架构，而是理解每种架构解决的问题
- apple 的MVC 解决了他们的问题，但不一定适合自己的问题
- 避免过度设计，在不必要的时候无需拆分
- 以用户更流畅的使用，而不是让开发者更轻松