没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
原创 分布式架构开发实战之一 故事起源
分布式架构开发实战之一 故事起源
前言:本系列文章主要讲述一个实实在在的项目开发的过程,主要包含:提出问题,
解决问题,架构设计和各个逻辑层的实现以及新问题的出现和代码的重构。本系列文章以
故事的形式展开,而且文章列举的很多项目的名称,大家也不用太关心,很多都是虚拟的。
系列文章链接
原创 分布式架构开发实战之一 故事起源
原创 分布式架构开发实战之二 草稿设计
原创 分布式架构开发实战之三 数据访问深入一点的思考
原创 分布式架构开发实战之四 构建从理想和实现之间的桥梁 前篇
原创 分布式架构开发实战五
改进篇
原创 业务框架开发实战之六
的重构
原创 业务框架开发实战之七 业务层初步构想
原创 业务框架开发实战之八 业务层
的选择策略
原创 业务框架开发实战之九
属性原理和验证规则的实现策略
原创 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
原创 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)
本篇主要讲述项目的一些背景。
新人 被分配到了一个企业 自 动 化信息管 理 项 目组 !"#$"
!%&!后面简称 #,当 进入项目组的时候,这个项目已经开始了,
项目的架构也已经在两周之前构建好了 '( 架构,而且使用的主要技术也敲定了 )*+
,
注:因为项目是首次采用-新技术-因为以前没有使用 )*+,,所以被称为新技术,
项目就这样开始进行了。
半年之后问题就开始出现了其实问题就一开始就出现了,只是大家还认为问题不大:
因为当初在设计的时候,项目的架构是由项目组的其他两个人设计的,整个项目开发基本
上就没有采用面向对象的思想来开发,而且虽然在架构设计上分了:数据层,业务层,服
务层,和 .# 层,但是各层之前是紧紧的耦合,可以说是“牵一发而动全身”:如数据访问层
稍微一改,业务层就跟着动,然后改变一层层的开始波及。
大家都开始觉得这样很累,但是项目已经做到这个阶段了,不可能重来。每次新需求
一来,项目的的改动可以说是天翻地覆。而且当初设计架构的那位仁兄也就项目一开始的
一个月后就走了。
下面的图就展示项目中的架构设计:
咋一看起来还是不错的,一般的架构都是这样设计的。下面就开始讲述它们之间的一
些调用关系,看看有什么问题:
数据访问层:
/001102
3
/01!40256!00021
3
77
8
8
其中 02 就是 , 生成的一个实体对象。
业务层:
代码
/0011029
3
/01!40256!00021
3
0202:02;
! 026!00021;
8
8
服务层:
代码
/0!$#02'<1
3
1!40256!00021;
8
/001102'<1#02'<1
3
/01!40256!00021
3
029029:029;
! 0296!00021;
8
8
然后就是在客户端生成代理,然后在 .# 中就调用了提供的方法。
现在一个最明显的问题就是:把数据层的数据实体 02 一层层的传递,最后到了
客户端的 .# 代码中,而业务层中的 029 基本上没有起到什么作用,只是起到一个
过渡的作用,只是在 #1!,.!+和 0! 的时候,对一些字段进行了相应的 * 和
=0",如 0 格式是否正确等等。其他的一些流程的 * 也是代码的堆积,业务类
很-弱-。
总的看起来就是-牵一发而动全身-的效果。
而且在开发过程,分层的好处基本没有体现出来。
在业务类的设计的时候,所有的业务类都显得比较的-弱-,之所以这么说,主要是基于
这样的一个思想:
都知道,在面向“对象”设计的过程中,每个类就好比一个人,实例化一个类就好比生成
了一个人,这个人可以在一出生就具备很多的能力天生秉异,如异常处理,日志跟踪,
缓存,通用的验证机制等等;也可以一出生什么都不会或者只会做最基本的几件事情。
之前的业务类实例化之后就生成一个非常普通的人。每个类都得重写很多的基础代码,说
到通用那就只是 2 代码。如果想要使得新生成的类很强大,具备很多功能,在设计的时
候可以让这些类继承一个功能比较强大的基类。当然继承只是实现方式的一种。
现在 已经被分到了另外的一个项目组也是本系列文章要讲述的一个项目,就称
为项目进度管理系统—%&!%11!%%,而且担任了架构的设计和开发
之前的架构设计 没有发言权。有了前车之鉴,在新项目开发之前的 几个月 ,
首先就开始了通用架构的设计,目的有两个:
>解决之前项目的问题:不灵活,不通用,每次都做重复性的事情等。
?结合自己的考虑,开发一个 ,使得开发更加的快速,灵活,强大。
其实在项目真正开始了之后,不可能给你几个月的时间去设计架构的。其实在 # 出
现问题之后, 就已经在构思如果开发一个通用的 了(”通用”不表示就是
到处可用,因为公司的一直是开发某一领域软件的,比如现在的公司就擅长开发企业管理
的一些软件,所以开发出一个基于领域模型的架构和框架还是有可能的)。 也想挽
救 #,由于诸多原因,想法终究只是成了想法。
在从 # 项目出来之后, 又开始了另外的一个项目的开发,名称我们暂时就虚
拟的称为 '02!'21!+' 项目不是很大,公司解决让 一个
人开发这个项目。这个项目给了 很多的时间来考虑架构设计和 设计的时
间,因为 ' 项目不是很复杂,而且技术和进度都在掌控之中,在正常上班时间就可以到
时候定期交付。所以每天下班之后, 开始加班去构思 的设计,开发的时
间越长,技术就应该沉淀的越多,如以通用类库,组件的方式或者解决问题方案的文档等
出现。只有这样,下次的开发才更加的快速。
@ 个月下来,' 项目完成了。而且 设计的 也有了雏形。准确的说,
还只能称为 基础架构基本完成。' 没有采用这个 来开发,因为 的
设计和实现于 ' 是同步进行的。
心里是这样认为的:设计通用的架构,然后在项目中不断的锤炼,更新,产生
出通用的代码,然后演化为 。只有设计出了自己的 ,以后的开发才
有可能进入-光速开发-。
在这个项目开始之初, 就和其他几个组员讨论了如何实现,同时也推出了自己
开发的成果。商量之后,决定采用 的设计。
在 设 计 架 构 的 时 候 , 也 参 考 了 现 在 流 行 的 一 个 + 如
'+*'+/!,主要吸收它们的一些思想,同时也分析了这些
对自己项目的利弊。而且认为:没有绝对万能的技术,一个架构的实现需要在很多的因素
之间权衡,技术不是用来 1 的,而是用来解决问题,这就是技术的价值。
本系列文章就展示整个构思,设计,实现的过程。本系列文章所要开发的项目的价值
可能不大,本系列文章的价值在于架构的思考和设计过程,一步步的演化过程。
谢谢大家:)
下篇文章:分布式架构开发实战之二 草稿设计
欢迎大家参加企业级项目开发团队
剩余63页未读,继续阅读
资源评论
chen_dian_dian
- 粉丝: 13
- 资源: 19
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 论文(最终)_20240430235101.pdf
- 基于python编写的Keras深度学习框架开发,利用卷积神经网络CNN,快速识别图片并进行分类
- 最全空间计量实证方法(空间杜宾模型和检验以及结果解释文档).txt
- 5uonly.apk
- 蓝桥杯Python组的历年真题
- 2023-04-06-项目笔记 - 第一百十九阶段 - 4.4.2.117全局变量的作用域-117 -2024.04.30
- 2023-04-06-项目笔记 - 第一百十九阶段 - 4.4.2.117全局变量的作用域-117 -2024.04.30
- 前端开发技术实验报告:内含4四实验&实验报告
- Highlight Plus v20.0.1
- 林周瑜-论文.docx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功