首先架构要解决几个问题
- 如何让业务工程师更方便的调用网络api, 尽可能的在各种网络情况下都有良好的体验?
- 页面如何组织才能降低业务方的耦合度, 尽可能降低业务方界面开发的复杂度, 提高他们的效率.
- 当数据在本地有存取的需求的时候, 如何合理的安排?如何尽可能的减小性能的消耗
- iOS有审核周期, 如何紧急修复bug, 如何发布一些热更新?
总结起来也四点
- 网络层的设计方案
- 页面的展示,调用,组织都有那些方案
- 本地持久化的方案
- 动态部署的方案
我们需要了解业务方的需求什么, 从而设计出合理的架构.
什么叫一个好的架构
- 代码整齐, 分类明确, 没有common, 没有core, 这么恶心的命名
- 不用文档, 业务方很容易上手
- 思路和方法要统一, 尽量不要多元
- 不要横向依赖, 不要跨层
- 对业务方该有限制的地方
- 容易测试
- 保持一定量的超前性
- 接口少, 接口参数少
- 高性能
数据层持久化方案
- 构造异步执行单例类(队列), 处理所有的数据库写入和读取的操作
- 数据库类&数据库池(不同的数据库连接)
