关于目前开发的app中网络数据请求架构的一点思考

讨论的前提：基于网络的请求是安全可靠的

1. 最基本的网络请求架构
2. 目前正在使用的架构
3. 理想的架构

• S 代表Server
• M 代表MessageCenter
• UI 代表用户界面
• DB 代表数据库
• MUI 代表程序主界面
• MS 代表Memory Storage

1.最基本的网络请求架构

直接由用户界面请求网络，并在界面的生命周期发生变化的时候控制网络请求，稍微厉害点的可能会将网络请求抽取成单独的数据提供层。这是最开始的时候会使用的方式。

优点：

• 结构单一，开发便利
• 无数据安全性问题

缺点：

• 与界面耦合太深
• 大量重复的网络请求

2.目前正在使用的架构

分两条线：

1.由用户发出通知告知主界面我在使用某某数据；主界面负责根据生命周期管理网络请求，收到通知后负责请求服务器获取最新数据，并将数据更新到内存中；并发出数据已更新的通知；界面更新；

2.用户界面直接从内存中获取“旧数据”展示

优点：

• 更高效的利用网络
• 无数据安全性问题
• 统一了数据来源，半分离了界面和服务器

缺点：

• 考虑到内存的有限性

需解决的问题：

• 数据第一次加载的问题

3.理想的架构

同上面一样，还是分两条线，唯一的区别在于将与服务器的交互抽离出来组成信息中心，并由单独的生命周期；数据存储由内存变成了数据库。

优点：

• 更高效的利用网络
• 将界面与网络完全分离
• 统一了数据来源
• 便于扩展和维护

缺点：

• 需考虑本地数据安全问题

需解决的问题：

• 数据第一次加载的问题
• 数据同步