设计模式之美
王争
前 Google 工程师,《数据结构与算法之美》专栏作者
123425 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 113 讲
设计模式与范式:行为型 (18讲)
设计模式之美
15
15
1.0x
00:00/00:00
登录|注册

24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?

VO、BO、Entity的封装特性
数据对象之间的转化
解决代码重复问题
VO、BO、Entity的设计思路
应对系统的复杂性
提高可测试性
隔离关注点
隔离变化
代码复用
业务模型设计
数据库设计
接口设计
课堂讨论
总结用到的设计原则和思想
BO、VO、Entity存在的意义是什么?
为什么要分MVC三层开发?
业务开发包括哪些工作?
如何实现一个积分兑换系统?

该思维导图由 AI 生成,仅供参考

上一节课中,我们讲了积分系统的需求分析和系统设计。今天,我们来讲它的代码实现。
上一节课中,我们把积分赚取和消费的渠道和规则的管理维护工作,划分到了上层系统中,所以,积分系统的功能变得非常简单。相应地,代码实现也比较简单。如果你有一定的项目开发经验,那实现这样一个系统,对你来说并不是件难事。
所以,我们今天讲解的重点,并不是教你如何来实现积分系统的每个功能、每个接口,更不是教你如何编写 SQL 语句来增删改查数据,而是给你展示一些更普适的开发思想。比如,为什么要分 MVC 三层来开发?为什么要针对每层定义不同的数据对象?最后,我还会总结这其中都蕴含哪些设计原则和思想,让你知其然知其所以然,做到真正地透彻理解。
话不多说,让我们正式开始今天的学习吧!

业务开发包括哪些工作?

实际上,我们平时做业务系统的设计与开发,无外乎有这样三方面的工作要做:接口设计、数据库设计和业务模型设计(也就是业务逻辑)。
数据库和接口的设计非常重要,一旦设计好并投入使用之后,这两部分都不能轻易改动。改动数据库表结构,需要涉及数据的迁移和适配;改动接口,需要推动接口的使用者作相应的代码修改。这两种情况,即便是微小的改动,执行起来都会非常麻烦。因此,我们在设计接口和数据库的时候,一定要多花点心思和时间,切不可过于随意。相反,业务逻辑代码侧重内部实现,不涉及被外部依赖的接口,也不包含持久化的数据,所以对改动的容忍性更大。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了如何实现一个积分兑换系统的代码实现。首先讲解了业务开发包括接口设计、数据库设计和业务模型设计三方面的工作。接着详细讨论了数据库设计和接口设计的重要性,以及业务模型的设计原则。作者强调了分层开发的重要性,分别从代码复用、隔离变化、隔离关注点、可测试性和应对系统复杂性等方面进行了解释。最后,作者建议将积分系统作为一个独立的项目进行开发,同时强调了模块化和解耦的重要性。整体而言,本文通过讲解积分系统的代码实现和分层开发原则,为读者提供了一些普适的开发思想和设计原则。 在文章中,作者提到了分层开发的重要性,包括代码复用、隔离变化、隔离关注点、可测试性和应对系统复杂性等方面的解释。此外,还介绍了VO、BO、Entity的设计思路,以及如何解决代码重复的问题。同时,文章还涉及了数据对象之间的转化和设计原则和思想的应用。读者可以从中学习到如何进行业务开发、数据库设计和接口设计,以及分层开发原则的重要性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《设计模式之美》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(139)

  • 最新
  • 精选
  • 李朝辉
    课堂讨论1: 业务驱动的系统还是应该从业务的角度出发去做设计,这两个字段在积分明细查询中是不可或缺的,所以我认为是合理的。既然是不可或缺的,如果不记录在这张表中,就要记录在其他表中,或者查询不便,或者破坏内聚。 2.根据个人经验,insert操作的都是返回记录id,原因的个人观点是为调用方提供便利。还请老师解答

    作者回复: 说的挺对的

    2019-12-27
    2
    80
  • 杨杰
    个人感觉:VO、BO、Entity 通过组合关系来复用这个类的代码不是特别好,尤其是VO。因为用组合的方式会增加返回数据的层次,这对前端来说是不是不不太友好?

    作者回复: 是的 主要是对象转json的格式问题

    2019-12-27
    4
    41
  • 辣么大
    反馈一个文章朗读的小问题:音频3:00左右 facade设计模式 应该读做/fə'sɑ:d/ ,冯老师读的不是很准确。 ”吹毛求疵“,希望专栏做的更专业。

    编辑回复: 应该吹毛求疵,我们fix去

    2019-12-27
    7
    36
  • 斐波那契
    老师 beanutils会不会性能不好 毕竟大量用到了反射 有没有代码不那么繁琐性能也比较好的方法

    作者回复: 对于大部分业务系统来说 数据库是最耗时的 对象转化那点性能损失可以忽略

    2019-12-31
    12
    21
  • 黄林晴
    打卡✔ 难道是我膨胀了,实战的内容没有理论看的起劲

    作者回复: 期望太高了 也不可能篇篇让你高潮

    2019-12-27
    6
    15
  • 胖子
    我有一个疑问:接口设计、数据库设计和业务模型设计如何对应或过渡到MVC分层?

    作者回复: 接口 controller层 数据库 repository 业务 service

    2019-12-27
    9
  • 杨陆伟
    VO、BO、Entity频繁的克隆、拷贝会不会引入性能问题,这点是怎么考虑的?谢谢

    作者回复: 虽然有性能损耗 但可以忽略 影响不大

    2020-01-02
    8
    6
  • 永旭
    3层架构 和 MVC 不是 2中概念吗 ? 3层架构: 表示层, 业务层 , 数据访问层 MVC: model , view , controller 3层架构.表示层 = MVC.controller + MVC.view ??

    作者回复: 表示层=view层吧 ,不过,现在后端的这种controller+service+repo 已经不能完全对应到mvc三层了

    2020-07-10
    2
    5
  • YsnowLove
    这篇文章是实战篇,为啥没有说明积分余额的设计,作为一个用户,首先关心的是积分余额吧。不可能每次看积分余额都要查询所以积分明细,然后计算一遍。

    作者回复: 增加一个总余额,就要维护数据的一致性了。就变得复杂了。而计算余额并非太复杂。当然,如果积分表中的数据量很大,那增加余额也是可以的。这个具体来看,没有说非得选择哪个设计更好。

    2020-06-22
    5
  • 为什么积分明细表没有user_id字段,如何查询用户的可用积分

    作者回复: 是个问题 我改下

    2020-01-02
    4
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部