1
00:00:03,680 --> 00:00:06,035
Na lição anterior,

2
00:00:06,035 --> 00:00:08,550
aprendemos sobre o driver do MongoDB.

3
00:00:08,550 --> 00:00:14,250
Isso permite que nosso aplicativo nó para se comunicar com um servidor MongoDB,

4
00:00:14,250 --> 00:00:19,660
e também armazenar e recuperar documentos do servidor MongoDB.

5
00:00:19,660 --> 00:00:23,310
Também vimos que o driver MongoDB nos fornece

6
00:00:23,310 --> 00:00:28,770
muitos métodos que nos permitem criar coleções dentro de um banco de dados,

7
00:00:28,770 --> 00:00:30,925
adicionar documentos às coleções

8
00:00:30,925 --> 00:00:35,695
e, em seguida, executar várias operações nos documentos dentro de uma coleção.

9
00:00:35,695 --> 00:00:41,060
Agora, quando os documentos são armazenados no banco de dados,

10
00:00:41,060 --> 00:00:46,330
o próprio driver MongoDB não impõe nenhuma estrutura sobre os documentos.

11
00:00:46,330 --> 00:00:52,640
Se precisamos ter estrutura específica para os documentos e impor essa estrutura,

12
00:00:52,640 --> 00:00:58,505
então precisamos fazer uso do módulo nó Mangusto que nos permite definir

13
00:00:58,505 --> 00:01:05,015
um esquema e uma estrutura para os nossos documentos que são armazenados em nosso banco de dados MongoDB,

14
00:01:05,015 --> 00:01:08,275
e rigorosamente impõe a estrutura.

15
00:01:08,275 --> 00:01:16,035
Vejamos mais detalhes nesta palestra e os exercícios que se seguem a esta palestra.

16
00:01:16,035 --> 00:01:18,540
Como já aprendemos,

17
00:01:18,540 --> 00:01:25,035
MongoDB armazena dados em coleções em um banco de dados.

18
00:01:25,035 --> 00:01:28,695
Estas coleções consistem em uma coleção de documentos.

19
00:01:28,695 --> 00:01:30,750
Os próprios documentos armazenados em

20
00:01:30,750 --> 00:01:35,405
um banco de dados MongoDB não têm nenhuma estrutura específica imposta ao documento.

21
00:01:35,405 --> 00:01:38,570
Qualquer documento pode ser armazenado em qualquer coleção.

22
00:01:38,570 --> 00:01:46,370
MongoDB depende do desenvolvedor para impor a estrutura sobre os documentos,

23
00:01:46,370 --> 00:01:52,295
e dá a responsabilidade completa para o desenvolvedor para se certificar de que os documentos

24
00:01:52,295 --> 00:01:58,670
da estrutura correta são adicionados e mantidos nas várias coleções.

25
00:01:58,670 --> 00:02:01,960
Agora, é muito fácil violar isso.

26
00:02:01,960 --> 00:02:06,260
Assim, por exemplo, mesmo que você possa começar com a suposição de

27
00:02:06,260 --> 00:02:11,030
que uma conexão específica terá documentos de uma determinada estrutura,

28
00:02:11,030 --> 00:02:17,045
você pode facilmente inserir documentos que não necessariamente estejam em conformidade com a estrutura.

29
00:02:17,045 --> 00:02:21,170
Se você é muito particular que a estrutura dos documentos em

30
00:02:21,170 --> 00:02:25,550
uma coleção sempre tem uma estrutura especificada,

31
00:02:25,550 --> 00:02:28,550
e sempre terá o conjunto específico de campos,

32
00:02:28,550 --> 00:02:32,540
então o próprio MongoDB não impõe que nem

33
00:02:32,540 --> 00:02:36,630
o nó MongoDB driver que vimos na lição anterior.

34
00:02:36,630 --> 00:02:40,565
Aqui é onde vamos precisar de uma maneira mais formal de impor

35
00:02:40,565 --> 00:02:46,385
estrutura sobre os documentos que são armazenados em uma coleção em um banco de dados MongoDB.

36
00:02:46,385 --> 00:02:52,390
É aqui que o módulo do nó Mangusto vem em nossa ajuda.

37
00:02:52,390 --> 00:02:56,405
O módulo do nó Mangusto impõe

38
00:02:56,405 --> 00:03:01,875
uma estrutura padronizada para os documentos que são armazenados em uma coleção específica.

39
00:03:01,875 --> 00:03:07,175
Então, é por isso que muitas vezes ouvimos pessoas se referindo a isso como o ODM Mangusto.

40
00:03:07,175 --> 00:03:10,950
O próprio ODM é interpretado por algumas pessoas para significar

41
00:03:10,950 --> 00:03:16,995
Modelo de Dados de Objeto ou às vezes referido como Mapeamento de Documento de Objeto,

42
00:03:16,995 --> 00:03:22,125
ou algumas pessoas se referem a ele como ORM ou Mapeamento Relacional de Objeto.

43
00:03:22,125 --> 00:03:27,755
Agora, quando falamos sobre relacional que se aplica muito mais a bancos de dados relacionais,

44
00:03:27,755 --> 00:03:33,380
mas então com bancos de dados SQL precisávamos explicitamente do objeto para

45
00:03:33,380 --> 00:03:41,850
mapeamento relacional para ser colocado entre o banco de dados e nosso próprio aplicativo.

46
00:03:41,850 --> 00:03:45,245
Porque dentro do aplicativo estaríamos olhando para

47
00:03:45,245 --> 00:03:50,245
objetos, mas seu armazenamento em um banco de dados SQL será na forma de registros,

48
00:03:50,245 --> 00:03:52,585
e assim você precisa de um mapeamento explícito.

49
00:03:52,585 --> 00:03:54,870
Como vimos com o banco de dados NoSQL,

50
00:03:54,870 --> 00:03:56,685
isso não era explicitamente necessário.

51
00:03:56,685 --> 00:04:03,710
Mas se você precisa impor estrutura em seus documentos que são armazenados em uma coleção

52
00:04:03,710 --> 00:04:10,790
, então o uso de Mangusto para impor essa estrutura é muito, muito útil.

53
00:04:10,790 --> 00:04:13,880
A maneira como Mangusto vai ao redor

54
00:04:13,880 --> 00:04:18,275
impondo estrutura sobre os documentos é através do uso de esquema.

55
00:04:18,275 --> 00:04:21,995
Esquema, define a estrutura de seus documentos.

56
00:04:21,995 --> 00:04:24,800
Vamos falar sobre isso com um pouco mais de detalhes.

57
00:04:24,800 --> 00:04:27,580
Então, o que exatamente é esquema de mangusto,

58
00:04:27,580 --> 00:04:29,700
e o que ele traz para a mesa?

59
00:04:29,700 --> 00:04:34,700
esquema Mangusto, implica uma estrutura sobre

60
00:04:34,700 --> 00:04:39,735
os dados que é armazenado em um documento em seu banco de dados.

61
00:04:39,735 --> 00:04:42,770
Então, ele define todos os campos de seu documento,

62
00:04:42,770 --> 00:04:45,349
e também especifica os tipos de campos,

63
00:04:45,349 --> 00:04:47,345
e também pode nos fornecer

64
00:04:47,345 --> 00:04:51,965
recursos adicionais que podem habilitar a validação nesses campos.

65
00:04:51,965 --> 00:04:59,425
Assim, por exemplo, os vários tipos de esquema suportados no Mangusto incluem: String,

66
00:04:59,425 --> 00:05:03,195
Number, Date, Buffer, Boolean,

67
00:05:03,195 --> 00:05:06,295
Misto, ID de objeto e Array.

68
00:05:06,295 --> 00:05:09,070
Em particular, vamos olhar para o número de string,

69
00:05:09,070 --> 00:05:14,405
e uma data, e booleano no exercício que se segue.

70
00:05:14,405 --> 00:05:18,075
Vamos olhar para alguns dos outros em exercícios posteriores.

71
00:05:18,075 --> 00:05:22,125
Em particular, observe o uso do tipo de esquema de matriz.

72
00:05:22,125 --> 00:05:25,570
Então, um tipo de esquema de matriz permitiria que você

73
00:05:25,570 --> 00:05:31,640
crie uma matriz de sub-documentos dentro do documento.

74
00:05:31,640 --> 00:05:33,740
Falarei sobre isso daqui a pouco.

75
00:05:33,740 --> 00:05:36,940
Depois de definir um esquema,

76
00:05:36,960 --> 00:05:42,160
o esquema é usado em Mangusto para criar uma função de modelo,

77
00:05:42,160 --> 00:05:49,830
e é isso que permite que você defina a estrutura para seus documentos no banco de dados.

78
00:05:49,830 --> 00:05:53,225
Esquemas em si podem ter aninhamento.

79
00:05:53,225 --> 00:05:58,490
Então, o que significa que você pode ter subdocumento que estão incluídos dentro de um documento.

80
00:05:58,490 --> 00:06:01,519
Os subdocumentos normalmente são acomodados

81
00:06:01,519 --> 00:06:04,890
através da especificação de um esquema adicional

82
00:06:04,890 --> 00:06:11,870
e, em seguida, definindo um dos campos do esquema para estar fora do tipo do outro esquema.

83
00:06:11,870 --> 00:06:15,215
Ou você pode até mesmo usar uma matriz de

84
00:06:15,215 --> 00:06:20,000
outro tipo de esquema dentro de um segundo esquema que você definir.

85
00:06:20,000 --> 00:06:24,930
Vejamos um exemplo para esclarecer alguns deles com mais detalhes.

86
00:06:24,930 --> 00:06:32,010
Este exemplo será do exercício que você fará logo após esta palestra.

87
00:06:32,010 --> 00:06:37,705
Antes que eu possa falar sobre esquemas e modelos em Mangusto,

88
00:06:37,705 --> 00:06:41,310
vamos entender por que precisaríamos disso.

89
00:06:41,310 --> 00:06:43,975
Se você tomou o angular anterior,

90
00:06:43,975 --> 00:06:46,760
ou o iônico, ou o curso de script nativo,

91
00:06:46,760 --> 00:06:49,445
você viu que representamos

92
00:06:49,445 --> 00:06:55,565
vários dados que usamos em nossas aplicações na forma de strings JSON.

93
00:06:55,565 --> 00:07:02,050
Então, em nossa aplicação, definimos uma coleção chamada como pratos.

94
00:07:02,050 --> 00:07:03,770
Em uma coleção de pratos,

95
00:07:03,770 --> 00:07:09,700
cada prato irá conter um certo conjunto de propriedades definidas na forma de string JSON,

96
00:07:09,700 --> 00:07:11,665
como você vê neste exemplo aqui.

97
00:07:11,665 --> 00:07:15,830
Então, os pratos são uma matriz de tipo prato,

98
00:07:15,830 --> 00:07:18,605
e cada prato em si conterá um nome,

99
00:07:18,605 --> 00:07:20,290
uma imagem, uma categoria,

100
00:07:20,290 --> 00:07:22,015
um rótulo, e assim por diante.

101
00:07:22,015 --> 00:07:26,360
Além disso, dentro do próprio documento prato,

102
00:07:26,360 --> 00:07:32,830
você teria comentários que são armazenados como uma matriz de novamente, -

103
00:07:32,830 --> 00:07:38,240
documentos JSON que contêm campos específicos passo.

104
00:07:38,240 --> 00:07:39,750
Então, cada comentário, por exemplo,

105
00:07:39,750 --> 00:07:45,685
contém um autor de comentário de classificação e um campo de data como você vê neste exemplo aqui.

106
00:07:45,685 --> 00:07:49,215
Então, você vê que há uma estrutura clara para

107
00:07:49,215 --> 00:07:55,230
cada documento que define um prato que é armazenado em nosso banco de dados.

108
00:07:55,230 --> 00:08:02,545
Múltiplos pratos, obviamente, serão armazenados na forma de uma coleção em nosso banco de dados,

109
00:08:02,545 --> 00:08:06,655
e podem ser agrupados e enviados como uma variedade de

110
00:08:06,655 --> 00:08:11,165
pratos para o nosso aplicativo cliente a ser usado.

111
00:08:11,165 --> 00:08:14,890
Agora que entendemos como isso é definido, agora,

112
00:08:14,890 --> 00:08:22,000
como isso se relaciona com o esquema Mangusto e o modelo que definimos em Mangusto?

113
00:08:22,000 --> 00:08:27,460
Agora, observe a estrutura de um documento típico prato aqui.

114
00:08:27,460 --> 00:08:34,095
Então, isso poderia ser facilmente mapeado em um documento MongoDB em uma coleção,

115
00:08:34,095 --> 00:08:37,375
talvez chamado a coleção de pratos.

116
00:08:37,375 --> 00:08:42,605
Então, vemos que há uma estrutura clara para o próprio documento.

117
00:08:42,605 --> 00:08:50,320
Agora, como espelhamos isso em um esquema em nosso aplicativo Mangusto?

118
00:08:50,320 --> 00:08:54,095
Como você aprenderá no exercício,

119
00:08:54,095 --> 00:08:57,900
veremos que definiríamos esquemas em Mangusto.

120
00:08:57,900 --> 00:09:03,085
Então, o esquema é definido como um esquema Mangusto aqui.

121
00:09:03,085 --> 00:09:08,055
Como exemplo, um CommentSchema é mostrado aqui.

122
00:09:08,055 --> 00:09:09,925
O CommentSchema, como você pode ver,

123
00:09:09,925 --> 00:09:13,885
contém três campos diferentes: a classificação, comentário

124
00:09:13,885 --> 00:09:15,445
e o campo autor,

125
00:09:15,445 --> 00:09:18,745
e também carimbos de data/hora aqui.

126
00:09:18,745 --> 00:09:23,560
Os carimbos de data/hora permitem que você tenha dois campos diferentes no

127
00:09:23,560 --> 00:09:28,850
documento: o campo criado em e o campo atualizado em,

128
00:09:28,850 --> 00:09:38,200
ambos os quais são carimbos de data/hora armazenados na forma de uma string de data ISO no documento.

129
00:09:38,200 --> 00:09:43,615
Agora, a classificação em si seria um valor inteiro.

130
00:09:43,615 --> 00:09:46,400
Então, na terminologia Mangusto,

131
00:09:46,400 --> 00:09:48,755
ele será armazenado como um número,

132
00:09:48,755 --> 00:09:50,680
o tipo seria um número.

133
00:09:50,680 --> 00:09:53,660
Você pode até especificar o valor mínimo e máximo.

134
00:09:53,660 --> 00:09:57,190
Você também pode especificar que esse campo específico é obrigatório, portanto,

135
00:09:57,190 --> 00:10:04,460
o que significa que cada documento do tipo de comentário deve conter um campo de classificação.

136
00:10:04,460 --> 00:10:07,370
Da mesma forma, você também pode definir um campo de comentário,

137
00:10:07,370 --> 00:10:08,710
que é do tipo string.

138
00:10:08,710 --> 00:10:13,635
Então, obviamente, um comentário não é nada além de uma string que contém algumas informações,

139
00:10:13,635 --> 00:10:16,340
e isso também pode ser definido como um campo obrigatório, o

140
00:10:16,340 --> 00:10:18,805
que significa que cada documento deve conter um comentário,

141
00:10:18,805 --> 00:10:21,060
e também um campo de autor,

142
00:10:21,060 --> 00:10:22,800
que também é do tipo string.

143
00:10:22,800 --> 00:10:28,030
Então, você vê que definindo este esquema neste formato.

144
00:10:28,030 --> 00:10:32,600
Como aprendemos na discussão um pouco mais cedo,

145
00:10:32,600 --> 00:10:41,890
esquema é definido usando os vários tipos que temos em nossa aplicação Mangusto.

146
00:10:41,890 --> 00:10:43,030
Então, no esquema, novamente,

147
00:10:43,030 --> 00:10:44,900
você vê três campos diferentes aqui,

148
00:10:44,900 --> 00:10:47,135
classificação, comentário e autor aqui,

149
00:10:47,135 --> 00:10:50,665
e cada um dos quais tem um tipo específico dado,

150
00:10:50,665 --> 00:10:53,060
e então se isso é necessário ou não.

151
00:10:53,060 --> 00:10:56,505
Então, assim, você está impondo uma estrutura rigorosa

152
00:10:56,505 --> 00:11:01,320
sobre os documentos de comentários que serão armazenados em seu aplicativo.

153
00:11:01,320 --> 00:11:05,255
Agora que definimos um esquema de comentário, podemos então,

154
00:11:05,255 --> 00:11:12,254
como você notou a partir do exemplo do tipo de dados que exigimos em nossa aplicação,

155
00:11:12,254 --> 00:11:15,000
temos um documento prato em si.

156
00:11:15,000 --> 00:11:17,620
O documento prato contém vários campos.

157
00:11:17,620 --> 00:11:19,050
Aqui, no exercício,

158
00:11:19,050 --> 00:11:23,355
vamos primeiro introduzir apenas dois campos no documento prato,

159
00:11:23,355 --> 00:11:25,370
o nome e a descrição.

160
00:11:25,370 --> 00:11:27,010
Na próxima lição,

161
00:11:27,010 --> 00:11:32,330
apresentaremos os campos restantes para o DishSchema.

162
00:11:32,330 --> 00:11:33,680
Agora, então o nome,

163
00:11:33,680 --> 00:11:35,440
como neste caso,

164
00:11:35,440 --> 00:11:36,765
é do tipo string.

165
00:11:36,765 --> 00:11:39,450
Também podemos especificar que este é um campo obrigatório, o

166
00:11:39,450 --> 00:11:43,360
que significa que cada documento deve conter o campo de nome.

167
00:11:43,360 --> 00:11:46,385
Também podemos especificar que o campo de nome é exclusivo, o

168
00:11:46,385 --> 00:11:53,215
que significa que nenhum documento pode ter exatamente o mesmo valor de nome no documento.

169
00:11:53,215 --> 00:11:55,980
Então, isso garante que cada documento terá

170
00:11:55,980 --> 00:12:01,300
um campo de nome exclusivo nele e um campo de descrição,

171
00:12:01,300 --> 00:12:03,115
que é novamente da cadeia de caracteres de tipo,

172
00:12:03,115 --> 00:12:06,460
mas também especificado conforme necessário.

173
00:12:06,460 --> 00:12:10,010
Agora, como vimos no exemplo,

174
00:12:10,010 --> 00:12:15,750
um documento prato contém vários comentários incluídos dentro do documento.

175
00:12:15,750 --> 00:12:20,920
Agora, em Mangusto, isso é suportado através do uso de sub-documentos.

176
00:12:20,920 --> 00:12:24,230
Então, se você definir um esquema anteriormente,

177
00:12:24,230 --> 00:12:27,345
então, por exemplo, já definimos um CommentSchema aqui,

178
00:12:27,345 --> 00:12:33,370
você também pode definir um campo em outro esquema que você definir e, em

179
00:12:33,370 --> 00:12:36,240
seguida, especificar que esse campo será

180
00:12:36,240 --> 00:12:39,520
do tipo do esquema anterior que você definiu.

181
00:12:39,520 --> 00:12:40,960
Então, neste caso,

182
00:12:40,960 --> 00:12:44,360
o campo de comentários, eu estou definindo-o como uma matriz,

183
00:12:44,360 --> 00:12:51,545
para que você veja o uso de um tipo de matriz em seu esquema que você está definindo aqui

184
00:12:51,545 --> 00:12:55,110
e, em seguida, matriz do tipo CommentSchema.

185
00:12:55,110 --> 00:13:00,725
Então, esta é uma série de comentários que serão incluídos em cada documento prato.

186
00:13:00,725 --> 00:13:02,590
Então, assim, você pode ter

187
00:13:02,590 --> 00:13:11,640
mais de um subdocumento comentário fechado dentro de um documento prato.

188
00:13:11,640 --> 00:13:16,080
Então, definir a estrutura como esta nos permite suportar

189
00:13:16,080 --> 00:13:20,950
a estrutura string JSON correspondente que definimos

190
00:13:20,950 --> 00:13:26,470
para um documento prato ou que vimos no exemplo anteriormente.

191
00:13:26,470 --> 00:13:30,145
Agora, uma vez que definimos o esquema,

192
00:13:30,145 --> 00:13:33,695
para fazer uso disso em nossa aplicação,

193
00:13:33,695 --> 00:13:38,600
precisamos criar um modelo a partir desse esquema que acabamos de definir.

194
00:13:38,600 --> 00:13:40,640
Então, dentro da nossa aplicação,

195
00:13:40,640 --> 00:13:45,320
vamos definir um modelo Mangusto e especificar que o modelo

196
00:13:45,320 --> 00:13:51,085
está fora do tipo DishSchema neste exemplo.

197
00:13:51,085 --> 00:13:54,830
Não só isso, você também dará um nome ao modelo aqui.

198
00:13:54,830 --> 00:13:57,100
Então, quando você dá um nome para o modelo aqui,

199
00:13:57,100 --> 00:14:00,000
estamos especificando o nome como prato.

200
00:14:00,000 --> 00:14:03,860
Agora, quando você usa este modelo prato em

201
00:14:03,860 --> 00:14:07,870
nosso aplicativo nó onde estamos fazendo uso de Mangusto,

202
00:14:07,870 --> 00:14:15,280
então este será transformado e mapeado em uma coleção no meu banco de dados MongoDB.

203
00:14:15,280 --> 00:14:18,885
A coleção em si será nomeada como pratos.

204
00:14:18,885 --> 00:14:23,355
Então, Mangusto sabe automaticamente que quando você especificar um nome aqui,

205
00:14:23,355 --> 00:14:27,990
ele irá automaticamente construir o plural

206
00:14:27,990 --> 00:14:31,635
desse nome e, em seguida, dar a coleção o nome,

207
00:14:31,635 --> 00:14:37,160
que é o plural do nome do modelo que você especificar neste exemplo aqui.

208
00:14:37,160 --> 00:14:39,400
Então, quando eu disser prato aqui,

209
00:14:39,400 --> 00:14:42,620
então Mangusto automaticamente irá mapear isso

210
00:14:42,620 --> 00:14:46,365
na coleção de pratos no banco de dados MongoDB.

211
00:14:46,365 --> 00:14:53,385
Como é que ele sabe converter este nome singular para um plural?

212
00:14:53,385 --> 00:14:56,750
Mangusto tem automaticamente um mecanismo embutido

213
00:14:56,750 --> 00:15:01,795
que lhe permite construir os plurais de palavras padrão em inglês.

214
00:15:01,795 --> 00:15:02,965
Então, se você disser prato,

215
00:15:02,965 --> 00:15:04,170
ele construirá pratos.

216
00:15:04,170 --> 00:15:08,880
Se você diz líder, ele vai construir o plural dele como líderes, e assim por diante.

217
00:15:08,880 --> 00:15:13,250
Então, isso já está embutido no módulo do nó Mangusto.

218
00:15:13,250 --> 00:15:17,585
Então, é por isso que quando eu especificar isso como um tipo de modelo de prato,

219
00:15:17,585 --> 00:15:24,050
então Mangusto vai construir a coleção de pratos no meu banco de dados MongoDB,

220
00:15:24,050 --> 00:15:27,155
e então essa coleção de pratos irá armazenar

221
00:15:27,155 --> 00:15:33,050
os vários documentos do tipo de prato lá.

222
00:15:33,050 --> 00:15:35,780
Uma vez que tenhamos criado que, tipicamente,

223
00:15:35,780 --> 00:15:38,150
quando declaramos modelos em nossa aplicação,

224
00:15:38,150 --> 00:15:43,780
nós os armazenaríamos em uma sub-pasta denominada models, apenas por conveniência.

225
00:15:43,780 --> 00:15:44,900
Você não precisa fazer isso,

226
00:15:44,900 --> 00:15:47,320
mas apenas para organizar seu aplicativo,

227
00:15:47,320 --> 00:15:50,635
nós normalmente armazenamos isso em uma pasta chamada models.

228
00:15:50,635 --> 00:15:55,010
Em seguida, o esquema e o modelo seriam

229
00:15:55,010 --> 00:15:59,470
definidos em um arquivo como este como você vê no exemplo aqui,

230
00:15:59,470 --> 00:16:05,230
este chamado dishes.js, e então isso seria exportado porque este é um módulo de nó.

231
00:16:05,230 --> 00:16:10,970
Isto será exportado a partir deste arquivo para que ele possa ser incluído no aplicativo nó,

232
00:16:10,970 --> 00:16:13,100
onde vamos fazer uso

233
00:16:13,100 --> 00:16:16,620
deste esquema e do modelo que acabamos de definir aqui.

234
00:16:16,620 --> 00:16:20,540
Com este rápido entendimento de esquema e modelo e

235
00:16:20,540 --> 00:16:26,370
seu uso na definição da estrutura de um documento que armazenamos em um

236
00:16:26,370 --> 00:16:33,510
MongoDB, vamos voltar e entender um pouco mais sobre o que Mangusto nos fornece.

237
00:16:33,510 --> 00:16:39,965
Além disso, Mangusto nos permite estabelecer a conexão com o servidor MongoDB.

238
00:16:39,965 --> 00:16:43,070
Mangusto internamente fazer uso

239
00:16:43,070 --> 00:16:46,495
do driver MongoDB que tínhamos usado no exercício anterior.

240
00:16:46,495 --> 00:16:49,745
Então, Mangusto depende do driver MongoDB, então, o

241
00:16:49,745 --> 00:16:53,824
que significa que a partir de seu aplicativo de nó baseado em Mongoose,

242
00:16:53,824 --> 00:16:56,960
você pode usar todos os métodos que já estão

243
00:16:56,960 --> 00:17:01,040
disponíveis a partir do driver MongoDB também se você escolher,

244
00:17:01,040 --> 00:17:05,390
mas o próprio Mongoose tem sua própria coleção de métodos que

245
00:17:05,390 --> 00:17:09,940
podemos fazer uso de para interagir com o banco de dados MongoDB,

246
00:17:09,940 --> 00:17:13,645
como veremos no exercício que se segue.

247
00:17:13,645 --> 00:17:19,040
Permitam-me que lhes mostre brevemente como estabeleceríamos uma ligação à base de dados,

248
00:17:19,040 --> 00:17:21,590
e o senhor fará isso no exercício que se segue.

249
00:17:21,590 --> 00:17:25,280
Então, assim como declaramos o URL no caso

250
00:17:25,280 --> 00:17:29,160
do aplicativo nó MongoDB na lição anterior,

251
00:17:29,160 --> 00:17:32,630
ainda vamos declarar o URL para a nossa aplicação.

252
00:17:32,630 --> 00:17:36,965
Em seguida, vamos usar o método de conexão Mangusto

253
00:17:36,965 --> 00:17:40,180
e fornecer a URL para o método de conexão Mongoose,

254
00:17:40,180 --> 00:17:44,000
e isso irá estabelecer a conexão com o banco de dados.

255
00:17:44,000 --> 00:17:48,590
Com esta rápida compreensão de Mangusto e qual o papel que o Mangusto

256
00:17:48,590 --> 00:17:53,485
desempenha no suporte à inserção estruturada

257
00:17:53,485 --> 00:18:02,180
, armazenamento e recuperação de documentos do nosso

258
00:18:02,180 --> 00:18:07,920
Mongoose, vamos passar para o exercício onde teremos alguma experiência prática usando o módulo Mangusto.