场景分析：我们知道，一个移动设备的应用大多与网络有关，也就是说，我在移动设备上看到的数据，一般都是从Server上”拉“过来，显示在我们的移动设备（ios androiud、wpohone等）上。那我们就这个”拉“的过程分析，拉什么样的数据？去哪里拉？拉过来的数据怎么处理？用编程（开发）的思维看，就是定义什么实体（业务实体）、发送请求、解析数据。当然这也只是大体的过程。但从软件架构设计上讲，定义实体、发送请求、解析数据都是具有单独意义的模块。那我们怎么处理这些模块呢？
场景应用：sina weibo。定义timeline、user等实体；请求最新的微薄等；处理（主要是解析）请求的数据；最后是显示在移动设备的UI上。
回到前面的问题，我们该如何处理这个具有单独意义的模块呢？让我们借鉴下web的设计：
在传统的web系统设计中，数据库的访问、业务逻辑和UI设计混淆在一起，这样虽然直观，但一旦需求有所改动，对日后的维护带来很多不便。为了解决这个问题，人们提出了分层的架构思想。
分层架构模式：
"将解决方案的组件分隔到不同的层中，每一层中的组件应保持内聚性，各层保持松散耦合。" 分层模式是最常见的一种架构模式。在web应用系统开发中，比较流行三层架构（表现层、业务逻辑层、数据访问层），当然我们细分，也可以分层多层（我记得那时候我分七层）。
现时隔多年，如今反观移动App架构设计（对大程序而言，有人说移动设备很难开发大的系统，我不是完全赞同此说法），分层架构的设计仍然少不了。远的不说，就说IOS App的开发，苹果的设计是基于MVC的设计模式。
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范。MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。
我们细看下，其实他也是分层（三层）架构的。也就是说，它的设计思想也是分层。
既然MVC也是分层，那何不把App整体设计成分层架构，MVC保持原来的设计不变。将一些具有单独意义解决问题的模块分层，让他们服务于MVC呢？
那我可以分享（只是分享）一下我一个App的架构。如下：
