【架构设计】配置式金字塔架构

最近做一个项目,在项目搭建之前,花了些许时间去思考一下如何搭建一个合适的架构。一开始的构思是希望能合理的把应用的各部分进行分离,使其像金字塔一样从上往下,下层为上层提供功能。

在平常项目中,总是有很多应用级的变量,如果不合理存放,势必在项目变得越来越庞大的时候难以掌控。所以我基于这一关键点出发,定义出了第一层:配置层

基于配置层,我继承出总共5层,先把我的架构图贴上:

【系统配置层】

配置层负责存储应用内的通用变量,也就是可以在应用内多个界面或者模块中使用到的变量都会在这里预先配置,例如我会配置如下的变量:

(1)应用Application实例

(2)当前activity实例

(3)首页activity实例

(4)第三方SDK的Key

(5)当前登陆用户ID

所以在这一层我会定义出多个类进行分类存放,其中每个类都没有通信关系:

【数据存储层】

这一层通常定义一些应用内本地持久化存储的功能,因为一些小项目有时候不会要求做缓存功能,所以这一层可以为空,如果有通常我会定义一些功能如下:

(1)登陆账号存放功能,可以插入账号,然后把用过的账号列表拿出来

(2)某些功能模块的缓存,例如商品首页的数据缓存放在这里,可以无网的时候显示

(3)存放账号登陆后的一些个人信息,个人名称、手机号码等等

【系统API层】

这一层是比较重要的一层,包含了整个应用的业务逻辑功能,所以模块的功能都在这里体现,界面只是直接调用这一层的功能进行数据渲染,系统API层内部会定义很多基础功能,例如网络请求、JSON解析等待,然后封装这些功能,对外提供各种业务逻辑的实现。这一层可以根据自己的架构设计,在这一层内部进行细分,从而编写适合自己项目的内部架构。

(1)账号功能:登陆功能、忘记密码、注册帐号

(2)商品模块:获取商品列表、获取商品详情

上面的图中,ServerFace、ServerLogin就是对外提供的业务逻辑实现,封装得相当完善,下层只需要调用就可以获取想要得数据。毫不夸张的说,这一层相当于在控制台运行的APP,通过指令获取想要的数据,之后你的数据可以自由发挥渲染到界面上去。

【系统应用层】

这一层很好理解,就是应用的界面层,每一个界面都是独立,界面调用系统应用层的数据进行渲染。

这一层内,我根据自己实际需要,在BaseActivity定义了逻辑,例如Activity启动的时候,将当前实例赋值到配置层的当前启动Activity变量中。

【系统启动层】

这一层相当简单,其实就是Application实例入口,简单的项目Application内通常只有一些初始化的代码,例如将Application实例存放到配置层的变量中。

原文地址:https://www.cnblogs.com/nicojerry/p/10337193.html

时间: 2024-11-09 01:30:50

【架构设计】配置式金字塔架构的相关文章

.NET应用架构设计—重新认识分层架构(现代企业级应用分层架构核心设计要素)

阅读目录: 1.背景介绍 2.简要回顾下传统三层架构 3.企业级应用分层架构(现代分层架构的基本演变过程) 3.1.服务层中应用契约式设计来解决动态条件不匹配错误(通过契约式设计模式来将问题在线下暴露出来) 3.2.应用层中的应用控制器模式(通过控制器模式对象化应用层的职责) 3.3.业务层中的命令模式(事务脚本模式的设计模式运用,很好的隔离静态数据) 4.服务层作为SOA契约公布后DTO与业务层的DomainModel共用基本的原子类型 5.两种独立业务层职责设计方法(可以根据具体业务要求来搭

架构设计之如何写架构设计说明书

架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键.编制架构设计说明书是开发人员向架构师转变必定会经历的过程.在架构师整个的成长过 程中,必定会经历编制架构设计说明书.评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程.作为一个架构师,我想尝试一下根据这三个过程对不 同能力需要,写一次系列文章,包括<架构设计三部曲之如何写架构设计说明书>.<架构设计三部曲之如何评审架构设计说明书>以及<架构设计三部曲之如何做 架构设计>,一来可以帮助自己整理思路,重新

分享JAVA从初级程序员到架构师视频,文档,架构设计,大型网站架构分析,大数据分析资料

JAVA从初级程序员到架构师视频,文档,架构设计,大型网站架构分析,大数据分析资料, 搭建高并发.高可用电商架构设计资料需要的联系我.很多目录都没列出来(QQ空间相册里有很多目录的截图)加QQ:1927360914

架构设计之如何评审架构设计说明书

自从5月8号写完架构设计三部曲的第一部如何写架构设计说明书,到现在快20多天了,这段时间主要准备了下系统分析师的考试,当然还有各种工作上的 杂事,于是也就拖到现在写第二部如何评审架构设计说明书.当然这个是从评审的角度来看的,其实从编制架构设计说明书的角度来看,也可以阐述具体如何编写架 构设计说明书,就像高考作文一样,评审总是有些采分点的嘛,那么对于编制架构设计说明书来说,哪些是我们应该准备的采分点呢?我们在编制的过程中需要重点 注意哪些章节的哪些内容呢?这就是我接下来想和大家分享的. 根据第一部

.NET应用架构设计—再次了解分层架构(现代企业应用分层架构核心设计元素)

阅读文件夹: 1.背景介绍 2.简要回想下传统三层架构 3.企业级应用分层架构(现代分层架构的基本演变过程) 3.1.服务层中应用契约式设计来解决动态条件不匹配错误(通过契约式设计模式来将问题在线下暴露出来) 3.2.应用层中的应用控制器模式(通过控制器模式对象化应用层的职责) 3.3.业务层中的命令模式(事务脚本模式的设计模式运用,非常好的隔离静态数据) 4.服务层作为SOA契约发布后DTO与业务层的DomainModel共用主要的原子类型 5.两种独立业务层职责设计方法(能够依据详细业务要求

OpenStack之路: OpenStack架构设计指南 - 一般用途云架构(摘录并翻译)

第二章. 一般用途General purpose 目录 用户需求 技术考虑因素 运维考虑因素 架构体系 规范性示例 一般用途云架构是开始建设云实施的常常被考虑使用的方案,这种价格原本就是被设计为平衡所有组件,而且在整个计算环境中不强调任何特殊因素.云架构的设计必须给予计算.网络,及存储组件相同的权重.一般用途云架构在私有云.公有云及混合云环境中都较常见,这也就使得这种价格可以用于很多不同的案例. 注: 一般用途云架构是均匀分布部署的,而且不适合用于特殊环境或者边缘使用案例. 一般用途云架构的常见

架构设计实践一:架构设计过程

节奏 做好架构设计需要做到看透需求.架构大方向正确.设计好架构的各个方面. 看透需求要求既要把需求找全,也要把需求项之间的矛盾关系.追溯关系搞清楚.需求找全可使用二维需求矩阵,从业务级.用户级.开发级和广义功能.质量.约束两个维度来找.一个矛盾关系的例子是安全性和互操作性的矛盾:一个追溯关系的例子是需求范围与系统目标的关系. 架构大方向正确是指要做好概念架构设计,概念架构重视“找对路子”,关注做好架构模式选型.集成技术选型等,不关注明确的接口定义.产品彩页上印的架构.售前提到的架构.投标使用的架

脑图学习架构设计之三:核心架构要素

【转】Flume(NG)架构设计要点及配置实践

Flume(NG)架构设计要点及配置实践 Flume NG是一个分布式.可靠.可用的系统,它能够将不同数据源的海量日志数据进行高效收集.聚合.移动,最后存储到一个中心化数据存储系统中.由原来的Flume OG到现在的Flume NG,进行了架构重构,并且现在NG版本完全不兼容原来的OG版本.经过架构重构后,Flume NG更像是一个轻量的小工具,非常简单,容易适应各种方式日志收集,并支持failover和负载均衡. 架构设计要点 Flume的架构主要有一下几个核心概念: Event:一个数据单元