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

本篇文章主要介绍了"关于目前开发的app中网络数据请求架构的一点思考"，主要涉及到方面的内容，对于Android开发感兴趣的同学可以参考一下： 讨论的前提：基于网络的请求是安全可靠的最基本的网络请求架构目前正在使用的架构理想的架构S 代表ServerM 代表MessageCenterUI 代表用户界面D...

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

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

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

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

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

优点：

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

缺点：

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

2.目前正在使用的架构

分两条线：

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

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

优点：

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

缺点：

• 考虑到内存的有限性

需解决的问题：

• 数据第一次加载的问题

3.理想的架构

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

优点：

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

缺点：

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

需解决的问题：

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

以上就介绍了关于目前开发的app中网络数据请求架构的一点思考，包括了方面的内容，希望对Android开发有兴趣的朋友有所帮助。

本文网址链接：http://www.codes51.com/article/detail_107137.html