[图解]企业应用架构模式2024新译本讲解26-层超类型2

1

00:00:00,510 --> 00:00:03,030

这个时候,如果再次查找所有人员

2

00:00:03,040 --> 00:00:03,750

我们会发现

3

00:00:05,010 --> 00:00:06,370

这一次所有的对象

4

00:00:06,740 --> 00:00:08,690

都是来自标识映射的

5

00:00:10,540 --> 00:00:13,390

就不需要再把数据库里面的

6

00:00:13,770 --> 00:00:16,610

加载到标识映射

7

00:00:16,620 --> 00:00:17,890

因为所有的都在里面

8

00:00:19,250 --> 00:00:20,120

我们来看一下

9

00:00:22,200 --> 00:00:23,320

这个是一样的

10

00:00:25,220 --> 00:00:32,040

这个地方跟之前一样

11

00:00:34,270 --> 00:00:36,830

但是这里面还是要查询一下

12

00:00:38,200 --> 00:00:39,990

案例就这样写的,没办法

13

00:00:54,060 --> 00:00:55,870

在这里,这个地方

14

00:00:56,680 --> 00:01:02,140

这时候,根据ID来判断这个的时候

15

00:01:04,430 --> 00:01:05,100

都在里面

16

00:01:05,350 --> 00:01:11,300

也就是说所有的都是走这里的

17

00:01:11,310 --> 00:01:12,580

下面这个就不用了

18

00:01:13,540 --> 00:01:16,510

到这里都是走这个地方

19

00:01:18,060 --> 00:01:19,130

直接返回了

20

00:01:20,630 --> 00:01:21,740

每一个都是这样

21

00:01:22,890 --> 00:01:25,970

你看,这里也是,都是直接走这里

22

00:01:26,680 --> 00:01:27,630

直接返回

23

00:01:34,220 --> 00:01:36,260

一共几条

24

00:01:36,350 --> 00:01:37,260

4条

25

00:01:38,340 --> 00:01:42,780

每一条,1234,你看都是直接返回

26

00:01:52,850 --> 00:01:53,640

下面是一样的

27

00:01:53,730 --> 00:01:55,680

把它输出出来,一样的

1

00:00:00,750 --> 00:00:08,900

接下来,我们再来看更新,我们一步步往下走

2

00:00:09,400 --> 00:00:13,040

比如说,更新ID为1人员的属性值

3

00:00:13,640 --> 00:00:15,800

首先通过mapper

4

00:00:17,450 --> 00:00:21,570

调用find操作

5

00:00:21,860 --> 00:00:23,170

把1找出来

6

00:00:24,060 --> 00:00:26,050

我们看find操作

7

00:00:31,500 --> 00:00:32,460

这个操作

8

00:00:33,980 --> 00:00:37,800

它实际上是实现了

9

00:00:37,810 --> 00:00:39,200

PersonFinder接口

10

00:00:41,970 --> 00:00:45,800

里面定义的find方法

11

00:00:47,180 --> 00:00:47,690

12

00:00:51,560 --> 00:00:52,680

然后在这里面

13

00:00:52,970 --> 00:01:00,050

它又调用了超类定义的

14

00:01:00,770 --> 00:01:04,250

AbstractFind方法

15

00:01:05,650 --> 00:01:08,200

因为这里面,对查找来说

16

00:01:08,210 --> 00:01:11,120

对所有的根据ID查找

17

00:01:11,130 --> 00:01:13,960

对所有的领域对象一样

18

00:01:13,970 --> 00:01:16,800

你不管是Person也好

19

00:01:16,810 --> 00:01:17,880

Order也好

20

00:01:17,890 --> 00:01:20,760

都是ID,回来一个对象

21

00:01:23,190 --> 00:01:24,370

没有什么区别

22

00:01:25,860 --> 00:01:28,520

所以这个地方

23

00:01:29,310 --> 00:01:30,390

它直接调用

24

00:01:32,580 --> 00:01:33,180

抽象类

25

00:01:34,030 --> 00:01:35,540

就是层超类型的

26

00:01:35,550 --> 00:01:39,100

顶上的超类就可以了

27

00:01:39,670 --> 00:01:42,740

然后把它变成Person返回

28

00:01:43,250 --> 00:01:45,920

我们来看AbstractFind

29

00:01:48,710 --> 00:01:49,960

这是在这里定义的

30

00:01:52,610 --> 00:01:55,410

在抽象的映射器里面定义的

31

00:01:58,190 --> 00:02:01,110

ID进来,返回的是一个领域对象

32

00:02:01,950 --> 00:02:02,540

DomainObject

33

00:02:02,990 --> 00:02:06,390

也就是Person上面的超类

34

00:02:06,480 --> 00:02:07,870

最顶上超类

35

00:02:09,600 --> 00:02:10,430

我们看第一个

36

00:02:10,440 --> 00:02:14,180

直接调用了

37

00:02:14,190 --> 00:02:16,860

loadedmap的操作

38

00:02:17,070 --> 00:02:18,820

TryGetValue操作

39

00:02:20,110 --> 00:02:21,710

这个操作就一步到位

40

00:02:21,840 --> 00:02:22,790

给你个ID

41

00:02:23,790 --> 00:02:27,750

然后有就直接把它输出到DomainObject

42

00:02:30,740 --> 00:02:34,020

这里的输出参数这里来了

43

00:02:37,260 --> 00:02:38,730

显然我们这是有的

44

00:02:39,130 --> 00:02:44,420

我们有的,因为前面我们经过了加载

45

00:02:44,430 --> 00:02:45,340

插入

46

00:02:45,350 --> 00:02:46,380

肯定是有的了

47

00:02:47,040 --> 00:02:49,080

肯定能找到,如果找到,就返回

48

00:02:49,090 --> 00:02:52,110

肯定能找到,能找到

49

00:02:53,320 --> 00:02:54,000

返回

50

00:02:55,020 --> 00:02:56,140

如果找不到

51

00:02:56,150 --> 00:02:58,860

再从数据库加载,跟前面一样

52

00:03:00,000 --> 00:03:03,600

下面这个没有走了,像前面一样

53

00:03:07,240 --> 00:03:15,260

好,找到了,得到人员的对象

54

00:03:15,990 --> 00:03:19,380

得到了,然后就修改属性值

55

00:03:21,010 --> 00:03:22,720

名,赋值为Jack

56

00:03:23,650 --> 00:03:25,120

然后通过mapper的

57

00:03:26,740 --> 00:03:31,340

update操作更新

58

00:03:34,300 --> 00:03:34,700

对象

59

00:03:34,950 --> 00:03:39,900

把这个对象的属性值更新到数据库里面去

60

00:03:40,360 --> 00:03:44,510

这里调用了这个,这个update

61

00:03:44,520 --> 00:03:48,920

跟前面的入口是一样的

62

00:03:49,170 --> 00:03:51,440

因为这里面没有做抽象

63

00:03:51,450 --> 00:03:57,040

你看,我们前面查找和插入

64

00:03:57,630 --> 00:03:59,050

这两个都

65

00:03:59,060 --> 00:04:02,760

要么是在这里定义了查找

66

00:04:02,770 --> 00:04:12,220

要么是在这里定义了插入

67

00:04:15,110 --> 00:04:16,130

包括插入

68

00:04:17,230 --> 00:04:19,510

加载都被抽象出来了

69

00:04:19,830 --> 00:04:21,730

但是在这个示例里面

70

00:04:22,880 --> 00:04:24,740

包括书里面它也没有

71

00:04:25,230 --> 00:04:27,720

因为这个示例就复刻书上

72

00:04:28,030 --> 00:04:29,220

代码片段

73

00:04:29,790 --> 00:04:31,200

它也没有把这个提炼出来

74

00:04:31,290 --> 00:04:32,440

可能是要对比一下

75

00:04:32,450 --> 00:04:34,200

实际上要提炼也是可以提炼的

76

00:04:35,790 --> 00:04:39,360

因为你插入更新,一回事

77

00:04:40,330 --> 00:04:45,570

无非是构造一个,跟insert一样

78

00:04:45,700 --> 00:04:50,160

通过这个方法来构造SQL语句

79

00:04:50,170 --> 00:04:52,640

还有参数的集合

80

00:04:55,140 --> 00:04:56,650

这里是用硬编码的形式

81

00:04:57,590 --> 00:05:00,850

创建连接,打开连接,一样的

82

00:05:00,860 --> 00:05:07,240

然后,你看这个一个常量

83

00:05:07,760 --> 00:05:10,320

这里直接就用硬编码了

84

00:05:11,620 --> 00:05:14,810

然后一个一个添加参数一样的

85

00:05:15,350 --> 00:05:20,810

然后执行,我们就跳过去了

86

00:05:26,200 --> 00:05:33,560

这是更新人员的名

87

00:05:34,800 --> 00:05:36,630

这个更新还是比较简单的

88

00:05:38,560 --> 00:05:40,070

该有的知识点我们前面

89

00:05:40,080 --> 00:05:42,070

也都大多说过了

90

00:05:42,320 --> 00:05:43,470

所以比较简单

相关推荐
deephub2 小时前
Tokenformer:基于参数标记化的高效可扩展Transformer架构
人工智能·python·深度学习·架构·transformer
架构师那点事儿3 小时前
golang 用unsafe 无所畏惧,但使用不得到会panic
架构·go·掘金技术征文
W Y5 小时前
【架构-37】Spark和Flink
架构·flink·spark
Gemini19956 小时前
分布式和微服务的区别
分布式·微服务·架构
Dann Hiroaki14 小时前
GPU架构概述
架构
茶馆大橘14 小时前
微服务系列五:避免雪崩问题的限流、隔离、熔断措施
java·jmeter·spring cloud·微服务·云原生·架构·sentinel
coding侠客15 小时前
揭秘!微服务架构下,Apollo 配置中心凭啥扮演关键角色?
微服务·云原生·架构
lipviolet16 小时前
架构系列---高并发
架构
Phodal16 小时前
架构赋能 AI:知识工程推动下的软件架构数字化
人工智能·架构
曹申阳18 小时前
2. JVM的架构模型和生命周期
jvm·架构