场景分析：我们知道，一个移动设备的应用大多与网络有关，也就是说，我在移动设备上看到的数据，一般都是从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的架构。如下：
