彦祖们，写 CRUD 的时候会使用设计模式吗？

彦祖

CRUD

模式

多此一举

47 条回复 • 2021-06-16 08:58:02 +08:00

1

billlee

2021-06-14 13:27:57 +08:00

CRUD 都是框架搞好设计模式，我们照着框架文档用就行了吧

2

x940727

OP

2021-06-14 13:32:28 +08:00

@billlee CRUD 难道就永远都是 Controller -> Service -> Dao，然后 if 、else 、for 就完事了吗？总归要有点追求的吧，而且这样的代码约束小，复用性差，改动起来风险大，随着代码量越来越多，还会出现很多重复代码，毕竟业务肯定会耦合，你写一下我写一下，看起来就很乱了。

3

sheeta

2021-06-14 14:07:08 +08:00

策略模式，模板模式整了一点

4

BeautifulSoap

2021-06-14 14:12:53 +08:00

等等 lz 你完全搞错了一件事，设计模式只是用来设计小组件或部分功能时的，不是用来设计整个程序或系统的，设计模式也帮不上这种忙

lz 你想要设计出一个更健壮的软件或系统，需要的是别的方面知识。比如 Layered Architecture 。再上面点就是 DDD 了，或者 Clean Architecture 这些

5

bnm965321

2021-06-14 14:21:38 +08:00

对第三方服务时候，各种 Adapter Pattern 应该写了不少

6

janus77

2021-06-14 14:27:40 +08:00

最简单一个，单例总会写吧？

7

MarkLeeyun

2021-06-14 14:44:03 +08:00

追求代码复用嘛。用点设计模式，但不要太复杂。避免给自己挖坑。

8

ericgui

2021-06-14 15:40:24 +08:00

适度复用代码是好的，但你不能为了复用而复用
我见过那种为了复用而复用的蠢货，最后还是一坨屎

9

ikas

2021-06-14 15:49:16 +08:00

你无时无刻不在用设计模式

10

Cbdy

2021-06-14 15:55:20 +08:00 via Android

CRUD，看一下 Clean Code 我觉得就可以了

11

chendy

2021-06-14 17:10:43 +08:00

设计模式不是强行上的
需要有比较复杂的业务和合适的场景才能用

12

Ariver

2021-06-14 17:36:36 +08:00 via iPhone

jdbc 是线程安全的吗

13

raaaaaar

2021-06-14 17:40:22 +08:00 via Android

不要故意去套就行，除非是单纯学习。如果经验比较丰富的话，哪些场景可以用都有数了，而如果没什么经验，建议在你感觉自己无法掌握了，感觉复杂度比较高的时候就可以考虑用了

14

jtsai

2021-06-14 17:49:27 +08:00

5

cs 这个学科，我想不到有什么比设计模式更没用的知识

15

x940727

OP

2021-06-14 18:32:26 +08:00

@BeautifulSoap DDD 这个东西，严格实行目前来看并不是一个很现实的想法，顶多借鉴部分思想，因为这个玩意目前来看，业务方面要求编程人员有全局认知，技术方面要求程序员有高度抽象的能力。这就不符合现在大部分程序员都是螺丝钉，哪里有用往哪搬的情况。

16

x940727

OP

2021-06-14 18:36:21 +08:00

@BeautifulSoap 还有我说的三层架构不就是 Layered Architecture 么……主要是在代码不停迭代的过程中，会出现相同功能的代码多次开发的情况，因为有可能原来的业务不完全适用，但是大部分适用的情况，这种情况如果设计巧妙一点的话，就可以复用了。

17

wolfie

2021-06-14 18:42:32 +08:00

扩展功能或者新功能复用老代码时候再重构。
有些框架源码追读是真的累。

18

Mutoo

2021-06-14 18:55:50 +08:00 via iPhone

个人觉得 Functional Programming 更适合 CRUD

19

renmu123

2021-06-14 19:12:13 +08:00 via Android

不会，又不是不能用.jpg

20

BeautifulSoap

2021-06-14 19:30:31 +08:00

@x940727

你的意思是你同时有参与一堆项目，然后发现这些项目一些功能模块是可以共用的，但是不完全共用，所以想看看是不是能用设计模式解决这个问题让它们共用？

如果是这样的话，没人能给你具体的答案。因为不同业务逻辑和模块千差万别，我们不是你，并不知道这些业务功能到底怎么回事，适用什么设计模式。有可能你翻翻设计模式可以找到合适的解决方法，但实际上大部分情况是没有任何一种设计模式能解决你现成的业务抽象问题（当然单例模式、工厂方法这些简单的类生成的设计模式是例外）

那么解决这个问题的核心是什么，是对业务的建模和抽象能力。往往代码设计的问题源于建模抽象做得有一定问题。你说的似乎能共用但又不能共用，那一个可能性就是你的建模抽象做得还不够，那就需要你不断持续地重新设计模型、重构代码，找到一个能共用的模型，还觉得不够你可以找你的组员一起帮你思考和抽象（到这地步就是个团队交流的问题了）。但是理想是美好的，现实是没有银弹的，最终结果可能就单纯只是这代码你看着像能共用能抽象但实际上根本不能。

我说了这么多看起来似乎是什么都没说的空话，但是的确事实也就是这样，你的问题来源于各种业务的抽象，但我们这些旁观的人不是你也无法帮你建模。所以我才说你真要找答案，就往更高的那一层去找，比如 DDD 这个，虽然的确 DDD 可以很宏观很抽象，但也有 Entity, ValueObject，约束的设计之类比较细节的东西可以提供参考。抽象的问题你肯定得借助一些更抽象的东西

21

x940727

OP

2021-06-14 19:35:42 +08:00

@Mutoo 我也是这么认为的。

22

x940727

OP

2021-06-14 19:36:28 +08:00

@BeautifulSoap 其实并不是同时参与一堆项目，而是一个项目有很多人参与开发，然后每个人对于业务的理解程度，还有技术水平都有出入，就导致在设计上有缺失，随着项目功能开发的越来越多，就导致项目当中有很多很多重复的代码。就比如说现在有个充值功能，然后支付完成后回调这个动作会有很多种后续操作，但是因为一开始的支付并没有考虑这么多，就导致回调的处理代码随着业务增加写了一份又一份，这如果使用策略模式的话就会香很多，所以就问问大家有没有在项目当中使用到设计模式。

23

kaedea

2021-06-14 20:44:32 +08:00 via Android

CAP 模式

24

shakoon

2021-06-14 21:28:16 +08:00 via Android

用啊，一些常用的查询会做成函数或者存储过程

25

Leviathann

2021-06-14 21:32:22 +08:00

现在比较倾向于认为 design pattern 是一种语言
用来交流的

26

crclz

2021-06-14 21:55:32 +08:00

首先 web 框架（ aspnetcore springboot ）就在很大程度上帮你规划了代码。
另外，DDD 其实不难的。如果觉得 DDD 难，不知道有没有认真去读 IDDD 这本书。DDD 的战略层面的核心在于按照领域领域知识分离关注点（模块化），战术层面的核心在于按照函数依赖来分离关注点（模块化）。这种模块化的设计思路是不以语言、框架为转移的。总的来说 DDD 是一个只有学习成本、没有使用成本的东西，说什么落地难都是扯淡。

27

xckai123

2021-06-14 21:57:39 +08:00

设计模式写框架或者基础层用的多，平常基于框架写业务实现基本上就是堆基础代码；如果是个人项目就算了，如果是小组协作项目，反而是最基础的代码大家很容易理解你的思路，可以快速接手；自己在主框架外实现一些自己的设计模式你让跟你协作的人或者接手你项目的人情何以堪，轮 shishan 是怎么堆成的？

28

msaionyc

2021-06-14 22:55:45 +08:00 via iPhone

不要为了用一样东西而用

29

bthulu

2021-06-15 09:20:52 +08:00

crud 要个毛的设计模式, 宁愿复制粘贴, 不比你设计模式跳来跳去的香的多

30

linbiaye

2021-06-15 09:26:41 +08:00

如果是比较重要的项目，建议还是 oo 这一套，否则各种逻辑堆积在臃肿的 service，两三年后接手的开发就是心里一万句 mmp，愤而重构。虽然最后都会成为屎山，设计模式能大大减缓屎山的形成速度。

31

x940727

OP

2021-06-15 09:46:09 +08:00

@crclz 一个人当然没有学习成本，一个团队有没有学习成本呢？不知道你对 DDD 理解这么深刻，有在团队里面推行这个东西吗？推行的结果怎么样呢？反正我是试过了，效果非常差。DDD 这个东西，有句话叫 [问就是都知道，用过没有就是都没有] 不是没有原因的。

32

kahlkn

2021-06-15 09:57:37 +08:00

我觉得如果是单纯的业务系统中的业务代码部分，大概率很难碰到。碰到的话，因为思维惯性，也会考虑 if else 方式解决。我之前碰到过一个根据传入的 Code 走不同业务的需求，if else 也能解决，策略模式也能解决。大致就是业务代码中设计模式很难碰到，碰到了也是惯性的 if else 。

不过如果写的是框架代码，每个公司都会有的自己的框架包的那种代码，那里面出现涉及模式的概率比业务代码大得多了。

33

autulin

2021-06-15 10:15:13 +08:00

会的，看业务，设计模式用对了可以使代码更清晰，以及少写很多代码

34

polyang

2021-06-15 10:32:40 +08:00

自己 CRUD 时很难有机会用到设计模式，顶多用用单例和建造者这些，设计模式一般在框架中用的比较多一点。

35

312ybj

2021-06-15 10:32:44 +08:00

我大概一年前也问过类似的问题，那时候我特别想学习并实践设计模式。别人说别为了设计模式而设计模式，问题是我都没用过，我都不知道该不该用，后来我尽量去凑使用场景。大概使用了策略模式职责链模式，使用 code 代替 if else, 使用 handler 代替 service，再参考一些技术帖子 https://mp.weixin.qq.com/s/qRjn_4xZdmuUPQFoWMBQ4Q ，感觉还是有点收获的，学习设计模式还是能提高自己的抽象能力的。还有网上大部分案例真的不怎么滴，给的案例都是 system.out ，真正的业务给你整这个？？？建立楼主还是多找点使用场景，使用设计模式，到时候便能体会到底好不好用。设计模式一定要学，也一定要用。
https://juejin.cn/post/6937158601584672804
https://juejin.cn/post/6959141486143209485

36

A555

2021-06-15 10:41:49 +08:00

策略用的多点

37

LarryWang

2021-06-15 10:55:44 +08:00

1

完全不需要。
人生苦短，CRUD，我用无远：enhancer.io

38

reactsub1

2021-06-15 11:00:17 +08:00

从实战的角度来讲，凭个人长期 CRUD 的开发和经验来讲，真的没有什么必要。即便是写大型互联网应用，基于 API, 微服务解耦程序，提高复用度即可。在面对一个具体的 CRUD 功能模块实现上，谈不上任何设计模式。

39

zardly666

2021-06-15 11:09:27 +08:00

1

一般会用策略+模板方法+责任链

40

a719031256

2021-06-15 13:43:31 +08:00

@x940727 你这想法太理想了，或者说你还是 cs 思想，现在 java 写业务用原来那套会疯的

41

Foredoomed

2021-06-15 14:55:56 +08:00

设计模式只会增加好多类文件，变相增加工作量，面向 so 编程复制黏贴完事了。

42

gdtdpt

2021-06-15 15:45:48 +08:00

想使用设计模式，最简单的办法就是提高自己的代码规范要求。
比如最简单的两条：
1.文件代码除注释外不超过 150 行(包括空行)
2.单个方法不得超过 30 行(包括空行)

当你编码的时候加了以上限制你会发现原本一些过长的代码必须封装，一些大段大段的 if-else 必须搞点工厂方法之类的才行，一些方法拆吧拆吧后发现拆出来的东西其实差不多……之类的事

43

Leviathann

2021-06-15 15:56:44 +08:00

策略模式大家是怎么用的，定义 interface 然后写各种 implements 那套
还是 function + lambda ？
其实引入了高阶函数可以减少很多所谓的 design pattern
或者说很多 design pattern 就是为了解决 90 年代的 C++ java 那套基于 class 的 oop 不得不搞的一套模板