1
00:00:00,000 --> 00:00:04,480
[MÚSICA]

2
00:00:04,480 --> 00:00:09,994
No desenvolvimento web você costuma ouvir pessoas falando sobre a estrutura MVC e

3
00:00:09,994 --> 00:00:13,020
a estrutura MVVM e assim por diante.

4
00:00:13,020 --> 00:00:14,460
O que exatamente são esses frameworks?

5
00:00:15,560 --> 00:00:20,050
Como eles são úteis para fazer desenvolvimento web?

6
00:00:20,050 --> 00:00:22,257
Vamos falar sobre isso brevemente a seguir.

7
00:00:24,177 --> 00:00:26,688
No mundo da engenharia de software,

8
00:00:26,688 --> 00:00:31,140
você costuma ouvir pessoas falando sobre padrões de design.

9
00:00:31,140 --> 00:00:37,470
O que exatamente eles querem dizer é parar de reinventar a roda toda vez.

10
00:00:37,470 --> 00:00:43,880
Um padrão de design é uma solução bem documentada para um problema recorrente.

11
00:00:43,880 --> 00:00:48,540
Muitas vezes, você se vê resolvendo repetidamente problemas semelhantes.

12
00:00:48,540 --> 00:00:53,860
Se temos uma documentação bem especificada de como resolver esses problemas,

13
00:00:53,860 --> 00:00:56,720
por que continuar reinventando a roda toda vez?

14
00:00:56,720 --> 00:00:59,140
Então é aí que se origina o conceito de padrão de design do software

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

16
00:01:03,220 --> 00:01:08,420
Às vezes você também vê pessoas que se referem a isso como um padrão de arquitetura.

17
00:01:08,420 --> 00:01:13,094
Então, para resumir, os padrões de design de software em particular são uma solução reutilizável

18
00:01:13,094 --> 00:01:17,706
para problemas comuns que são resolvidos no software.

19
00:01:17,706 --> 00:01:22,209
Agora, neste contexto, você costuma ouvir pessoas falando sobre a gangue de quatro.

20
00:01:23,830 --> 00:01:29,217
Este foi um grupo de quatro autores que escreveram este livro seminal chamado

21
00:01:29,217 --> 00:01:35,390
Design Patterns: Elements of Reusable Object-Oriented Software.

22
00:01:35,390 --> 00:01:39,500
Neste livro, eles identificaram um grande conjunto de padrões de design

23
00:01:39,500 --> 00:01:41,770
comumente usados em engenharia de software.

24
00:01:41,770 --> 00:01:48,030
Esta foi uma das primeiras explorações bem documentadas de padrões de design,

25
00:01:48,030 --> 00:01:53,370
e, portanto, tornou-se o padrão-ouro para qualquer pessoa que trabalha na engenharia de software

26
00:01:53,370 --> 00:01:58,410
, especialmente preocupado com pacotes de design.

27
00:01:58,410 --> 00:02:03,320
Este padrão de engenharia de software nos permite isolar a lógica de domínio

28
00:02:03,320 --> 00:02:06,706
da interface de usuário.

29
00:02:06,706 --> 00:02:11,827
Então você está basicamente separando a visão do usuário das informações

30
00:02:11,827 --> 00:02:17,146
da lógica real e como as informações armazenadas e manipuladas.

31
00:02:17,146 --> 00:02:22,280
Agora esta separação de preocupações conceito que você vai estar ouvindo mais e

32
00:02:22,280 --> 00:02:25,600
mais novamente neste contexto.

33
00:02:25,600 --> 00:02:30,290
A separação de preocupações é o que facilita o desenvolvimento independente de

34
00:02:30,290 --> 00:02:34,700
cada uma dessas três partes de nossa aplicação e

35
00:02:34,700 --> 00:02:39,350
também permite testes e manutenção dessas diferentes partes.

36
00:02:39,350 --> 00:02:42,640
Agora podemos dividir todo o nosso aplicativo em três partes,

37
00:02:42,640 --> 00:02:46,820
a visão que se preocupa principalmente com a apresentação de informações ao usuário,

38
00:02:46,820 --> 00:02:51,930
o modelo que armazena o estado do domínio e a lógica do domínio e

39
00:02:51,930 --> 00:02:57,430
também fornece a maneira de

40
00:02:57,430 --> 00:03:02,604
manipular este estado a partir do resto do aplicativo e

41
00:03:02,604 --> 00:03:08,180
o controlador que medeia entre a exibição e o modelo.

42
00:03:08,180 --> 00:03:12,550
Falaremos sobre cada uma dessas três partes em um pouco mais de detalhes a seguir.

43
00:03:12,550 --> 00:03:17,360
Na estrutura MVC, o modelo gerencia o comportamento e os dados

44
00:03:17,360 --> 00:03:19,760
do domínio do aplicativo.

45
00:03:19,760 --> 00:03:25,433
E o modelo responde a solicitações de informações sobre seu estado atual.

46
00:03:25,433 --> 00:03:30,374
Então, normalmente quando a exibição quer renderizar, ou a exibição quer atualizar

47
00:03:30,374 --> 00:03:35,065
em si, ele pode consultar o modelo para obter informações para

48
00:03:35,065 --> 00:03:38,703
que ele possa ser renderizado adequadamente para o usuário.

49
00:03:38,703 --> 00:03:45,632
O modelo também responderá a solicitações de alteração de seu estado.

50
00:03:45,632 --> 00:03:48,574
Isso geralmente é feito através do controle.

51
00:03:48,574 --> 00:03:51,712
Em um sistema orientado por eventos,

52
00:03:51,712 --> 00:03:57,810
o modelo também pode ser configurado para notificar observadores.

53
00:03:57,810 --> 00:04:02,670
Assim, os espectadores podem se registrar como observadores para o modelo e, portanto,

54
00:04:02,670 --> 00:04:06,940
quando o modelo for atualizado, as exibições serão automaticamente acionadas para

55
00:04:06,940 --> 00:04:10,960
se atualizarem com base na alteração nesse estado do modelo.

56
00:04:12,160 --> 00:04:17,290
A visão em si é preocupação em apresentar as informações aos usuários em um elemento de interface do usuário

57
00:04:17,290 --> 00:04:23,690
de tal forma que facilita tanto a apresentação de informações

58
00:04:23,690 --> 00:04:29,630
para o usuário e também permite que o usuário interaja com o aplicativo.

59
00:04:29,630 --> 00:04:33,970
Assim, a exibição pode representar uma representação do estado do modelo.

60
00:04:33,970 --> 00:04:38,662
Assim, a partir de um modelo único, você pode facilmente derivar várias maneiras

61
00:04:38,662 --> 00:04:43,449
apresentar essas informações ao usuário, dependendo do exemplo

62
00:04:43,449 --> 00:04:47,051
, dependendo do tamanho da janela de exibição.

63
00:04:47,051 --> 00:04:51,840
Assim, um viewport de tamanho pequeno como em um aplicativo móvel,

64
00:04:51,840 --> 00:04:57,359
as informações serão apresentadas de uma maneira diferente em oposição

65
00:04:57,359 --> 00:05:03,000
a uma porta de visualização maior que é facilitada em um computador desktop.

66
00:05:04,248 --> 00:05:08,620
Então, em uma estrutura MVC toda a exibição de informações tem uma correspondência de um a

67
00:05:08,620 --> 00:05:13,490
um com o estado do modelo.

68
00:05:15,850 --> 00:05:20,380
A terceira peça de quebra-cabeça na estrutura MCV é o controlador.

69
00:05:21,400 --> 00:05:26,750
O trabalho do controlador é receber informações da exibição.

70
00:05:26,750 --> 00:05:30,500
Assim, qualquer interação do usuário que for realizada será capturada e

71
00:05:30,500 --> 00:05:35,720
então passará para o controlador para atuar nessas interações do usuário.

72
00:05:35,720 --> 00:05:40,040
E é o trabalho do controlador, em seguida, iniciar uma mudança do estado de

73
00:05:40,040 --> 00:05:46,870
o modelo, se for necessário nesta situação particular.

74
00:05:46,870 --> 00:05:51,940
Assim, o controlador causará adequadamente a alteração do estado do modelo.

75
00:05:51,940 --> 00:05:55,940
Então, para resumir, o controlador pode aceitar a entrada

76
00:05:55,940 --> 00:06:00,860
do usuário em termos das interações do usuário que ocorreram, e

77
00:06:00,860 --> 00:06:06,935
então ele irá instruir o modelo para mudar o estado.

78
00:06:06,935 --> 00:06:09,500
Simultaneamente, o controlador também pode

79
00:06:09,500 --> 00:06:14,470
fazer com que a exibição altere a maneira como as informações estão sendo exibidas na exibição.

80
00:06:14,470 --> 00:06:19,230
Então essa é a razão pela qual nesta imagem você tem duas setas

81
00:06:19,230 --> 00:06:24,000
indo do controlador, uma em direção ao modelo e a outra em direção à vista.

82
00:06:25,060 --> 00:06:29,910
Às vezes você ouve as pessoas falando sobre a abordagem de modelo de visualização de modelo.

83
00:06:29,910 --> 00:06:33,490
A abordagem de modelo de visão de modelo é, em algum sentido,

84
00:06:33,490 --> 00:06:37,050
uma derivada da abordagem do controlador de visualização de modelo.

85
00:06:37,050 --> 00:06:40,620
Às vezes, você também ouve pessoas se referindo a ela como a abordagem de view-binder do modelo

86
00:06:40,620 --> 00:06:41,768
view.

87
00:06:41,768 --> 00:06:45,502
Aqui, você tem o modelo que representa a lógica de negócios e

88
00:06:45,502 --> 00:06:47,311
os dados para seu aplicativo.

89
00:06:47,311 --> 00:06:52,367
Do modelo, você deriva um modelo de exibição, que encapsula essa parte

90
00:06:52,367 --> 00:06:58,095
das informações necessárias para renderizar uma exibição específica.

91
00:06:58,095 --> 00:07:02,635
Assim, o view-model é a abstração da view que expõe

92
00:07:02,635 --> 00:07:07,395
as propriedades públicas e os vários comandos que estão disponíveis.

93
00:07:07,395 --> 00:07:10,125
Então, isso fornece uma ligação de dados declarativa.

94
00:07:11,690 --> 00:07:16,300
Em algum sentido, a maneira como o componente e

95
00:07:16,300 --> 00:07:21,520
os modelos em angular são implementados, ele pode ser visto como

96
00:07:21,520 --> 00:07:27,250
uma variante da visão de modelo de abordagem de visão de modelo.

97
00:07:27,250 --> 00:07:32,006
Com esta rápida compreensão do MVC e da estrutura MVVM,

98
00:07:32,006 --> 00:07:36,686
vamos agora continuar a entender mais sobre serviços angulares.

99
00:07:36,686 --> 00:07:43,099
[MÚSICA]