1
00:00:00,000 --> 00:00:04,480
[MUSIC]

2
00:00:04,480 --> 00:00:09,994
В веб-разработке вы часто слышите, как люди говорят о фреймворке MVC и

3
00:00:09,994 --> 00:00:13,020
фреймворке MVVM и так далее.

4
00:00:13,020 --> 00:00:14,460
Что именно представляют собой эти рамки?

5
00:00:15,560 --> 00:00:20,050
Как они полезны в веб-разработке?

6
00:00:20,050 --> 00:00:22,257
Давайте поговорим об этом вкратце.

7
00:00:24,177 --> 00:00:26,688
В мире разработки программного обеспечения

8
00:00:26,688 --> 00:00:31,140
вы часто слышите, как люди говорят о шаблонах проектирования.

9
00:00:31,140 --> 00:00:37,470
Что именно они означают, чтобы перестать изобретать колесо каждый раз.

10
00:00:37,470 --> 00:00:43,880
Шаблон проектирования является хорошо документированным решением повторяющейся проблемы.

11
00:00:43,880 --> 00:00:48,540
Очень часто вы видите себя неоднократно решая подобные проблемы.

12
00:00:48,540 --> 00:00:53,860
Если у нас есть четко определенная документация о том, как решить эти проблемы,

13
00:00:53,860 --> 00:00:56,720
зачем продолжать изобретать колесо каждый раз?

14
00:00:56,720 --> 00:00:59,140
Таким образом, именно здесь возникает концепция шаблона проектирования программного обеспечения

15
00:00:59,140 --> 00:01:03,220
.

16
00:01:03,220 --> 00:01:08,420
Иногда вы также видите людей, ссылающихся на это как на архитектуру.

17
00:01:08,420 --> 00:01:13,094
Таким образом, шаблоны проектирования программного обеспечения, в частности, являются многоразовым решением

18
00:01:13,094 --> 00:01:17,706
для часто встречающихся проблем, которые решаются в программном обеспечении.

19
00:01:17,706 --> 00:01:22,209
Теперь в этом контексте вы часто слышите, как люди говорят о банде из четверых.

20
00:01:23,830 --> 00:01:29,217
Это была группа из четырех авторов, которые написали эту основополагающую книгу под названием

21
00:01:29,217 --> 00:01:35,390
Design Patterns: Элементы многоразового объектно-ориентированного программного обеспечения.

22
00:01:35,390 --> 00:01:39,500
В этой книге они определили большой набор часто используемых шаблонов дизайна

23
00:01:39,500 --> 00:01:41,770
в программной инженерии.

24
00:01:41,770 --> 00:01:48,030
Это было одним из первых хорошо документированных исследований шаблонов дизайна

25
00:01:48,030 --> 00:01:53,370
и, следовательно, стало золотым стандартом для тех, кто работает в сфере разработки программного обеспечения

26
00:01:53,370 --> 00:01:58,410
, особенно обеспокоенных пакетами проектирования.

27
00:01:58,410 --> 00:02:03,320
Этот шаблон разработки программного обеспечения позволяет изолировать логику домена

28
00:02:03,320 --> 00:02:06,706
от пользовательского интерфейса.

29
00:02:06,706 --> 00:02:11,827
Таким образом, вы в основном отделяете представление пользователя информации

30
00:02:11,827 --> 00:02:17,146
от фактической логики и того, как информация хранится и обрабатывается.

31
00:02:17,146 --> 00:02:22,280
Теперь эта концепция разделения проблем вы собираетесь услышать и

32
00:02:22,280 --> 00:02:25,600
снова в этом контексте.

33
00:02:25,600 --> 00:02:30,290
Разделение проблем - это то, что облегчает независимое развитие

34
00:02:30,290 --> 00:02:34,700
каждой из этих трех частей нашего приложения, а

35
00:02:34,700 --> 00:02:39,350
также позволяет тестировать и поддерживать эти различные части.

36
00:02:39,350 --> 00:02:42,640
Теперь мы можем разделить все наше приложение на три части,

37
00:02:42,640 --> 00:02:46,820
представление, которое в первую очередь связано с представлением информации пользователю,

38
00:02:46,820 --> 00:02:51,930
модель, которая хранит состояние домена и логику домена и

39
00:02:51,930 --> 00:02:57,430
также обеспечивает способ

40
00:02:57,430 --> 00:03:02,604
манипулирования этим состоянием из остальной части приложения и

41
00:03:02,604 --> 00:03:08,180
контроллер, который является посредником между представлением и моделью.

42
00:03:08,180 --> 00:03:12,550
Далее мы поговорим о каждой из этих трех частей чуть более подробно.

43
00:03:12,550 --> 00:03:17,360
В рамках MVC модель управляет поведением и

44
00:03:17,360 --> 00:03:19,760
данных домена приложения.

45
00:03:19,760 --> 00:03:25,433
И модель отвечает на запросы о предоставлении информации о ее текущем состоянии.

46
00:03:25,433 --> 00:03:30,374
Таким образом, как правило, когда представление хочет визуализировать, или представление хочет обновить

47
00:03:30,374 --> 00:03:35,065
само, он может запросить модель, чтобы получить информацию так

48
00:03:35,065 --> 00:03:38,703
, что она может быть отображен соответствующим образом пользователю.

49
00:03:38,703 --> 00:03:45,632
Модель также будет отвечать на запросы об изменении своего состояния.

50
00:03:45,632 --> 00:03:48,574
Это обычно делается через контроль.

51
00:03:48,574 --> 00:03:51,712
В системе, управляемой событиями,

52
00:03:51,712 --> 00:03:57,810
модель также может быть настроена для уведомления наблюдателей.

53
00:03:57,810 --> 00:04:02,670
Таким образом, зрители могут зарегистрироваться в качестве наблюдателей для модели и, следовательно,

54
00:04:02,670 --> 00:04:06,940
при обновлении модели представления будут автоматически запускаться для обновления

55
00:04:06,940 --> 00:04:10,960
на основе изменения этого состояния модели.

56
00:04:12,160 --> 00:04:17,290
Само представление касается представления информации пользователям в элементе интерфейса пользователя

57
00:04:17,290 --> 00:04:23,690
таким образом, что это облегчает как представление информации

58
00:04:23,690 --> 00:04:29,630
пользователю, так и позволяет пользователю взаимодействовать с приложением.

59
00:04:29,630 --> 00:04:33,970
Таким образом, представление может представлять одно представление состояния модели.

60
00:04:33,970 --> 00:04:38,662
Таким образом, из одной модели вы можете легко получить несколько способов

61
00:04:38,662 --> 00:04:43,449
представления этой информации пользователю, в зависимости от примера

62
00:04:43,449 --> 00:04:47,051
, в зависимости от размера окна просмотра.

63
00:04:47,051 --> 00:04:51,840
Таким образом, небольшой размер viewport, как в мобильном приложении,

64
00:04:51,840 --> 00:04:57,359
информация будет представлена по-другому, в отличие от

65
00:04:57,359 --> 00:05:03,000
к более большому порту просмотра, который облегчается на настольном компьютере.

66
00:05:04,248 --> 00:05:08,620
Таким образом, в рамках MVC все отображение информации имеет одно на

67
00:05:08,620 --> 00:05:13,490
одно соответствие с состоянием модели.

68
00:05:15,850 --> 00:05:20,380
Третья часть головоломки в рамках MCV является контроллером.

69
00:05:21,400 --> 00:05:26,750
Заданием контроллера является получение информации из представления.

70
00:05:26,750 --> 00:05:30,500
Таким образом, любое пользовательское взаимодействие, которое выполняется, будет захвачено и

71
00:05:30,500 --> 00:05:35,720
затем передано на контроллер, чтобы действовать на эти взаимодействия с пользователем.

72
00:05:35,720 --> 00:05:40,040
И это задача контроллера тогда инициировать изменение состояния

73
00:05:40,040 --> 00:05:46,870
модели, если это требуется в данной конкретной ситуации.

74
00:05:46,870 --> 00:05:51,940
Таким образом, контроллер соответствующим образом вызовет изменение состояния модели.

75
00:05:51,940 --> 00:05:55,940
Таким образом, чтобы подвести итог, контроллер может принять ввод

76
00:05:55,940 --> 00:06:00,860
от пользователя с точки зрения взаимодействия с пользователем, которые имели место, и

77
00:06:00,860 --> 00:06:06,935
тогда он будет инструктировать модель изменить состояние.

78
00:06:06,935 --> 00:06:09,500
Одновременно контроллер может также

79
00:06:09,500 --> 00:06:14,470
вызвать изменение представления информации в представлении.

80
00:06:14,470 --> 00:06:19,230
Так вот почему на этой картинке у вас есть две стрелки

81
00:06:19,230 --> 00:06:24,000
, идущие от контроллера, одна к модели, а другая к виду.

82
00:06:25,060 --> 00:06:29,910
Иногда вы слышите, как люди говорят о подходе модели представления модели.

83
00:06:29,910 --> 00:06:33,490
Подход модели представления модели является, в некотором смысле,

84
00:06:33,490 --> 00:06:37,050
производной подхода контроллера представления модели.

85
00:06:37,050 --> 00:06:40,620
Иногда вы также слышите, как люди ссылаются на него как на модель

86
00:06:40,620 --> 00:06:41,768
view-binder подхода.

87
00:06:41,768 --> 00:06:45,502
Здесь у вас есть модель, которая представляет бизнес-логику и

88
00:06:45,502 --> 00:06:47,311
данные для вашего приложения.

89
00:06:47,311 --> 00:06:52,367
Из модели выводится модель view-model, которая инкапсулирует ту

90
00:06:52,367 --> 00:06:58,095
часть информации, которая необходима для рендеринга определенного вида.

91
00:06:58,095 --> 00:07:02,635
Таким образом, модель представления представляет собой абстракцию представления, которая предоставляет

92
00:07:02,635 --> 00:07:07,395
общедоступные свойства и различные доступные команды.

93
00:07:07,395 --> 00:07:10,125
Таким образом, это обеспечивает декларативную привязку данных.

94
00:07:11,690 --> 00:07:16,300
В некотором смысле, способ реализации компонента и

95
00:07:16,300 --> 00:07:21,520
шаблонов в угловых, его можно рассматривать как

96
00:07:21,520 --> 00:07:27,250
вариант модели view-model подхода.

97
00:07:27,250 --> 00:07:32,006
С этим быстрым пониманием MVC и MVVM рамки,

98
00:07:32,006 --> 00:07:36,686
давайте теперь перейдем к пониманию больше об угловых службах.

99
00:07:36,686 --> 00:07:43,099
[МУЗЫКА]