24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?
该思维导图由 AI 生成,仅供参考
业务开发包括哪些工作?
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何实现一个积分兑换系统的代码实现。首先讲解了业务开发包括接口设计、数据库设计和业务模型设计三方面的工作。接着详细讨论了数据库设计和接口设计的重要性,以及业务模型的设计原则。作者强调了分层开发的重要性,分别从代码复用、隔离变化、隔离关注点、可测试性和应对系统复杂性等方面进行了解释。最后,作者建议将积分系统作为一个独立的项目进行开发,同时强调了模块化和解耦的重要性。整体而言,本文通过讲解积分系统的代码实现和分层开发原则,为读者提供了一些普适的开发思想和设计原则。 在文章中,作者提到了分层开发的重要性,包括代码复用、隔离变化、隔离关注点、可测试性和应对系统复杂性等方面的解释。此外,还介绍了VO、BO、Entity的设计思路,以及如何解决代码重复的问题。同时,文章还涉及了数据对象之间的转化和设计原则和思想的应用。读者可以从中学习到如何进行业务开发、数据库设计和接口设计,以及分层开发原则的重要性。
《设计模式之美》,新⼈⾸单¥98
全部留言(139)
- 最新
- 精选
- 李朝辉课堂讨论1: 业务驱动的系统还是应该从业务的角度出发去做设计,这两个字段在积分明细查询中是不可或缺的,所以我认为是合理的。既然是不可或缺的,如果不记录在这张表中,就要记录在其他表中,或者查询不便,或者破坏内聚。 2.根据个人经验,insert操作的都是返回记录id,原因的个人观点是为调用方提供便利。还请老师解答
作者回复: 说的挺对的
2019-12-27280 - 杨杰个人感觉:VO、BO、Entity 通过组合关系来复用这个类的代码不是特别好,尤其是VO。因为用组合的方式会增加返回数据的层次,这对前端来说是不是不不太友好?
作者回复: 是的 主要是对象转json的格式问题
2019-12-27441 - 辣么大反馈一个文章朗读的小问题:音频3:00左右 facade设计模式 应该读做/fə'sɑ:d/ ,冯老师读的不是很准确。 ”吹毛求疵“,希望专栏做的更专业。
编辑回复: 应该吹毛求疵,我们fix去
2019-12-27736 - 斐波那契老师 beanutils会不会性能不好 毕竟大量用到了反射 有没有代码不那么繁琐性能也比较好的方法
作者回复: 对于大部分业务系统来说 数据库是最耗时的 对象转化那点性能损失可以忽略
2019-12-311221 - 黄林晴打卡✔ 难道是我膨胀了,实战的内容没有理论看的起劲
作者回复: 期望太高了 也不可能篇篇让你高潮
2019-12-27615 - 胖子我有一个疑问:接口设计、数据库设计和业务模型设计如何对应或过渡到MVC分层?
作者回复: 接口 controller层 数据库 repository 业务 service
2019-12-279 - 杨陆伟VO、BO、Entity频繁的克隆、拷贝会不会引入性能问题,这点是怎么考虑的?谢谢
作者回复: 虽然有性能损耗 但可以忽略 影响不大
2020-01-0286 - 永旭3层架构 和 MVC 不是 2中概念吗 ? 3层架构: 表示层, 业务层 , 数据访问层 MVC: model , view , controller 3层架构.表示层 = MVC.controller + MVC.view ??
作者回复: 表示层=view层吧 ,不过,现在后端的这种controller+service+repo 已经不能完全对应到mvc三层了
2020-07-1025 - YsnowLove这篇文章是实战篇,为啥没有说明积分余额的设计,作为一个用户,首先关心的是积分余额吧。不可能每次看积分余额都要查询所以积分明细,然后计算一遍。
作者回复: 增加一个总余额,就要维护数据的一致性了。就变得复杂了。而计算余额并非太复杂。当然,如果积分表中的数据量很大,那增加余额也是可以的。这个具体来看,没有说非得选择哪个设计更好。
2020-06-225 - 林为什么积分明细表没有user_id字段,如何查询用户的可用积分
作者回复: 是个问题 我改下
2020-01-024