1
00:00:03,680 --> 00:00:06,035
Nella lezione precedente,

2
00:00:06,035 --> 00:00:08,550
abbiamo imparato a conoscere il driver MongoDB.

3
00:00:08,550 --> 00:00:14,250
Ciò consente alla nostra applicazione nodo di comunicare con un server MongoDB,

4
00:00:14,250 --> 00:00:19,660
e anche memorizzare e recuperare documenti dal server MongoDB.

5
00:00:19,660 --> 00:00:23,310
Abbiamo anche visto che il driver MongoDB ci fornisce

6
00:00:23,310 --> 00:00:28,770
molti metodi che ci consentono di creare raccolte all'interno di un database,

7
00:00:28,770 --> 00:00:30,925
aggiungere documenti alle raccolte

8
00:00:30,925 --> 00:00:35,695
e quindi eseguire varie operazioni sui documenti all'interno di una raccolta.

9
00:00:35,695 --> 00:00:41,060
Ora, quando i documenti sono memorizzati nel database,

10
00:00:41,060 --> 00:00:46,330
il driver MongoDB stesso non impone alcuna struttura ai documenti.

11
00:00:46,330 --> 00:00:52,640
Se abbiamo bisogno di avere una struttura specifica per i documenti e applicare quella struttura,

12
00:00:52,640 --> 00:00:58,505
allora abbiamo bisogno di fare uso del modulo nodo Mongoose che ci permette di definire

13
00:00:58,505 --> 00:01:05,015
uno schema e una struttura per i nostri documenti che sono memorizzati nel nostro database MongoDB,

14
00:01:05,015 --> 00:01:08,275
e applica rigorosamente la struttura.

15
00:01:08,275 --> 00:01:16,035
Diamo un'occhiata a maggiori dettagli in questa lezione e agli esercizi che seguono questa lezione.

16
00:01:16,035 --> 00:01:18,540
Come abbiamo già imparato,

17
00:01:18,540 --> 00:01:25,035
MongoDB memorizza i dati in raccolte in un database.

18
00:01:25,035 --> 00:01:28,695
Queste raccolte sono costituite da una raccolta di documenti.

19
00:01:28,695 --> 00:01:30,750
I documenti stessi memorizzati in

20
00:01:30,750 --> 00:01:35,405
un database MongoDB non hanno alcuna struttura specifica imposta al documento.

21
00:01:35,405 --> 00:01:38,570
Qualsiasi documento può essere memorizzato in qualsiasi raccolta.

22
00:01:38,570 --> 00:01:46,370
MongoDB si affida allo sviluppatore per far rispettare la struttura sui documenti,

23
00:01:46,370 --> 00:01:52,295
e dà la piena responsabilità allo sviluppatore di assicurarsi che i documenti

24
00:01:52,295 --> 00:01:58,670
della struttura corretta vengano aggiunti e mantenuti nelle varie collezioni.

25
00:01:58,670 --> 00:02:01,960
Ora, è molto facile violare questo.

26
00:02:01,960 --> 00:02:06,260
Ad esempio, anche se si potrebbe iniziare con il presupposto

27
00:02:06,260 --> 00:02:11,030
che una particolare connessione avrà documenti di una determinata struttura,

28
00:02:11,030 --> 00:02:17,045
è possibile inserire facilmente documenti che non necessariamente sono conformi alla struttura.

29
00:02:17,045 --> 00:02:21,170
Se sei molto particolare che la struttura dei documenti in

30
00:02:21,170 --> 00:02:25,550
una raccolta abbia sempre una struttura specificata

31
00:02:25,550 --> 00:02:28,550
e avrai sempre il set specifico di campi,

32
00:02:28,550 --> 00:02:32,540
allora lo stesso MongoDB non impone che nemmeno

33
00:02:32,540 --> 00:02:36,630
il driver MongoDB nodo che abbiamo visto nella lezione precedente.

34
00:02:36,630 --> 00:02:40,565
Questo è dove avremo bisogno di un modo più formale di imporre

35
00:02:40,565 --> 00:02:46,385
la struttura sui documenti che sono memorizzati in una raccolta in un database MongoDB.

36
00:02:46,385 --> 00:02:52,390
Questo è dove il modulo nodo Mangusta viene in nostro aiuto.

37
00:02:52,390 --> 00:02:56,405
Il modulo nodo Mangoose impone

38
00:02:56,405 --> 00:03:01,875
una struttura standardizzata per i documenti memorizzati in una particolare raccolta.

39
00:03:01,875 --> 00:03:07,175
Quindi, questo è il motivo per cui sentiamo spesso persone che si riferiscono a questo come l'ODM di Mangusta.

40
00:03:07,175 --> 00:03:10,950
L' ODM stesso viene interpretato da alcune persone per indicare

41
00:03:10,950 --> 00:03:16,995
Object Data Model o talvolta indicato come Object Document Mapping,

42
00:03:16,995 --> 00:03:22,125
o alcune persone si riferiscono ad esso come ORM o Object Relational Mapping.

43
00:03:22,125 --> 00:03:27,755
Ora, quando parliamo di relazionale che si applica molto di più ai database relazionali,

44
00:03:27,755 --> 00:03:33,380
ma poi con i database SQL avevamo bisogno esplicitamente dell'oggetto

45
00:03:33,380 --> 00:03:41,850
alla mappatura relazionale da inserire tra il database e la nostra applicazione stessa.

46
00:03:41,850 --> 00:03:45,245
Perché all'interno dell'applicazione staremmo guardando

47
00:03:45,245 --> 00:03:50,245
gli oggetti ma la loro memorizzazione in un database SQL sarà sotto forma di record,

48
00:03:50,245 --> 00:03:52,585
e quindi è necessario un mapping esplicito.

49
00:03:52,585 --> 00:03:54,870
Come abbiamo visto con il database NoSQL,

50
00:03:54,870 --> 00:03:56,685
questo non era esplicitamente richiesto.

51
00:03:56,685 --> 00:04:03,710
Ma se hai bisogno di imporre una struttura sui tuoi documenti che sono memorizzati in una raccolta

52
00:04:03,710 --> 00:04:10,790
allora l'uso di Mangusta per imporre questa struttura è molto, molto utile.

53
00:04:10,790 --> 00:04:13,880
Il modo in cui Mongoose va in giro

54
00:04:13,880 --> 00:04:18,275
imponendo struttura sui documenti è attraverso l'uso di schema.

55
00:04:18,275 --> 00:04:21,995
Schema, definisce la struttura dei loro documenti.

56
00:04:21,995 --> 00:04:24,800
Parliamo di questo in modo un po 'più dettagliato.

57
00:04:24,800 --> 00:04:27,580
Quindi, cos'è esattamente lo schema di mangusta

58
00:04:27,580 --> 00:04:29,700
e cosa porta al tavolo?

59
00:04:29,700 --> 00:04:34,700
Schema mangusta, implica una struttura

60
00:04:34,700 --> 00:04:39,735
sui dati memorizzati in un documento nel database.

61
00:04:39,735 --> 00:04:42,770
Quindi, definisce tutti i campi del documento,

62
00:04:42,770 --> 00:04:45,349
e specifica anche i tipi dei campi,

63
00:04:45,349 --> 00:04:47,345
e anche in grado di fornirci

64
00:04:47,345 --> 00:04:51,965
funzionalità aggiuntive che possono abilitare la convalida su questi campi.

65
00:04:51,965 --> 00:04:59,425
Quindi, ad esempio, i vari tipi di schema supportati in Mongoose includono: String,

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

67
00:05:03,195 --> 00:05:06,295
Mixed, ID oggetto e Array.

68
00:05:06,295 --> 00:05:09,070
In particolare vedremo il numero di stringa,

69
00:05:09,070 --> 00:05:14,405
e una data, e booleano nell'esercizio che segue.

70
00:05:14,405 --> 00:05:18,075
Vedremo alcuni degli altri negli esercizi successivi.

71
00:05:18,075 --> 00:05:22,125
In particolare, si noti l'uso del tipo di schema di array.

72
00:05:22,125 --> 00:05:25,570
Quindi, un tipo di schema di array consentirebbe di

73
00:05:25,570 --> 00:05:31,640
creare una matrice di documenti secondari all'interno del documento.

74
00:05:31,640 --> 00:05:33,740
Ne parlerò tra un po'.

75
00:05:33,740 --> 00:05:36,940
Una volta definito uno schema,

76
00:05:36,960 --> 00:05:42,160
lo schema viene utilizzato in Mongoose per creare una funzione del modello,

77
00:05:42,160 --> 00:05:49,830
ed è ciò che consente di definire la struttura per i documenti nel database.

78
00:05:49,830 --> 00:05:53,225
Gli schemi stessi possono avere nidificazione.

79
00:05:53,225 --> 00:05:58,490
Quindi, il che significa che è possibile avere documenti secondari che sono racchiusi all'interno di un documento.

80
00:05:58,490 --> 00:06:01,519
I documenti secondari in genere vengono ospitati

81
00:06:01,519 --> 00:06:04,890
specificando uno schema aggiuntivo

82
00:06:04,890 --> 00:06:11,870
e quindi definendo uno dei campi dello schema per essere fuori dal tipo dell'altro schema.

83
00:06:11,870 --> 00:06:15,215
Oppure puoi anche andare con una matrice di un

84
00:06:15,215 --> 00:06:20,000
altro tipo di schema all'interno di un secondo schema che definisci.

85
00:06:20,000 --> 00:06:24,930
Diamo un'occhiata a un esempio per chiarire alcuni di questi in modo più dettagliato.

86
00:06:24,930 --> 00:06:32,010
Questo esempio sarà tratto dall'esercizio che farai subito dopo questa lezione.

87
00:06:32,010 --> 00:06:37,705
Prima di poter parlare di schemi e modelli in Mongoose,

88
00:06:37,705 --> 00:06:41,310
cerchiamo di capire perché ne avremmo bisogno.

89
00:06:41,310 --> 00:06:43,975
Se hai preso il precedente angolare,

90
00:06:43,975 --> 00:06:46,760
o lo ionico, o il corso di script nativo,

91
00:06:46,760 --> 00:06:49,445
hai visto che rappresentiamo

92
00:06:49,445 --> 00:06:55,565
vari dati che usiamo nelle nostre applicazioni sotto forma di stringhe JSON.

93
00:06:55,565 --> 00:07:02,050
Quindi, nella nostra applicazione definiamo una collezione chiamata come piatti.

94
00:07:02,050 --> 00:07:03,770
In una raccolta di piatti,

95
00:07:03,770 --> 00:07:09,700
ogni piatto conterrà un certo insieme di proprietà definite sotto forma di stringa JSON,

96
00:07:09,700 --> 00:07:11,665
come si vede in questo esempio qui.

97
00:07:11,665 --> 00:07:15,830
Quindi, i piatti sono una matrice di tipo piatto,

98
00:07:15,830 --> 00:07:18,605
e ogni piatto stesso conterrà un nome,

99
00:07:18,605 --> 00:07:20,290
un'immagine, una categoria

100
00:07:20,290 --> 00:07:22,015
, un'etichetta e così via.

101
00:07:22,015 --> 00:07:26,360
Inoltre, all'interno del documento piatto stesso,

102
00:07:26,360 --> 00:07:32,830
avresti commenti che vengono memorizzati come una matrice di

103
00:07:32,830 --> 00:07:38,240
documenti JSON che contengono campi specifici step.

104
00:07:38,240 --> 00:07:39,750
Quindi, ogni commento, ad esempio,

105
00:07:39,750 --> 00:07:45,685
contiene un autore commento di valutazione e un campo data, come si vede in questo esempio qui.

106
00:07:45,685 --> 00:07:49,215
Quindi, si vede che c'è una struttura chiara per

107
00:07:49,215 --> 00:07:55,230
ogni documento che definisce un piatto che è memorizzato nel nostro database.

108
00:07:55,230 --> 00:08:02,545
Più piatti ovviamente saranno conservati sotto forma di una raccolta nel nostro database,

109
00:08:02,545 --> 00:08:06,655
e potrebbero essere raggruppati insieme e inviati come una serie di

110
00:08:06,655 --> 00:08:11,165
piatti alla nostra applicazione cliente da utilizzare.

111
00:08:11,165 --> 00:08:14,890
Ora che abbiamo capito come questo è definito, ora,

112
00:08:14,890 --> 00:08:22,000
come si riferisce allo schema Mongoose e al modello che definiamo in Mongoose?

113
00:08:22,000 --> 00:08:27,460
Ora, nota la struttura di un tipico documento piatto qui.

114
00:08:27,460 --> 00:08:34,095
Quindi, questo potrebbe essere facilmente mappato in un documento MongoDB in una raccolta,

115
00:08:34,095 --> 00:08:37,375
forse chiamato collezione di piatti.

116
00:08:37,375 --> 00:08:42,605
Quindi, vediamo che c'è una struttura chiara al documento stesso.

117
00:08:42,605 --> 00:08:50,320
Ora, come facciamo a rispecchiare questo in uno schema nella nostra applicazione Mongoose?

118
00:08:50,320 --> 00:08:54,095
Come imparerete nell'esercizio,

119
00:08:54,095 --> 00:08:57,900
vedremo che definiremmo schemi in Mangusta.

120
00:08:57,900 --> 00:09:03,085
Quindi lo schema è definito come uno schema Mongoose qui.

121
00:09:03,085 --> 00:09:08,055
Ad esempio, un CommentSchema è mostrato qui.

122
00:09:08,055 --> 00:09:09,925
Il CommentSchema, come puoi vedere,

123
00:09:09,925 --> 00:09:13,885
contiene tre campi diversi: la valutazione, il commento

124
00:09:13,885 --> 00:09:15,445
e il campo autore,

125
00:09:15,445 --> 00:09:18,745
e anche i timestamp qui.

126
00:09:18,745 --> 00:09:23,560
I timestamp consentono di avere due campi diversi nel

127
00:09:23,560 --> 00:09:28,850
documento: il campo creato a e il campo aggiornato a,

128
00:09:28,850 --> 00:09:38,200
entrambi i quali sono timestamp memorizzati sotto forma di una stringa di data ISO nel documento.

129
00:09:38,200 --> 00:09:43,615
Ora, la valutazione stessa sarebbe un valore intero.

130
00:09:43,615 --> 00:09:46,400
Quindi, nella terminologia di

131
00:09:46,400 --> 00:09:48,755
Mangusta, verrà memorizzato come numero,

132
00:09:48,755 --> 00:09:50,680
il tipo sarebbe un numero.

133
00:09:50,680 --> 00:09:53,660
È anche possibile specificare il valore minimo e massimo.

134
00:09:53,660 --> 00:09:57,190
È inoltre possibile specificare che questo particolare campo è obbligatorio, quindi, il

135
00:09:57,190 --> 00:10:04,460
che significa che ogni documento del tipo di commento deve contenere un campo di valutazione.

136
00:10:04,460 --> 00:10:07,370
Allo stesso modo, è anche possibile definire un campo di commento,

137
00:10:07,370 --> 00:10:08,710
che è della stringa di tipo.

138
00:10:08,710 --> 00:10:13,635
Quindi, ovviamente, un commento non è altro che una stringa che contiene alcune informazioni,

139
00:10:13,635 --> 00:10:16,340
e questo può anche essere definito come un campo obbligatorio, il

140
00:10:16,340 --> 00:10:18,805
che significa che ogni documento dovrebbe contenere un commento,

141
00:10:18,805 --> 00:10:21,060
e anche un campo autore,

142
00:10:21,060 --> 00:10:22,800
che è anche della stringa di tipo.

143
00:10:22,800 --> 00:10:28,030
Quindi, si vede che definendo questo schema in questo formato.

144
00:10:28,030 --> 00:10:32,600
Come abbiamo imparato nella discussione un po 'prima,

145
00:10:32,600 --> 00:10:41,890
schema è definito utilizzando i vari tipi che abbiamo nella nostra applicazione Mongoose.

146
00:10:41,890 --> 00:10:43,030
Quindi, nello schema, ancora una volta,

147
00:10:43,030 --> 00:10:44,900
si vedono tre campi diversi qui,

148
00:10:44,900 --> 00:10:47,135
valutazione, commento e autore qui,

149
00:10:47,135 --> 00:10:50,665
e ognuno dei quali ha un tipo specifico dato,

150
00:10:50,665 --> 00:10:53,060
e quindi se questo è richiesto o meno.

151
00:10:53,060 --> 00:10:56,505
Quindi, in tal modo, stai imponendo una struttura rigorosa

152
00:10:56,505 --> 00:11:01,320
sui documenti di commento che verranno archiviati nella tua applicazione.

153
00:11:01,320 --> 00:11:05,255
Ora che abbiamo definito uno schema di commento, possiamo quindi,

154
00:11:05,255 --> 00:11:12,254
come avete notato dall'esempio del tipo di dati che abbiamo bisogno nella nostra applicazione,

155
00:11:12,254 --> 00:11:15,000
abbiamo un documento piatto stesso.

156
00:11:15,000 --> 00:11:17,620
Il documento piatto contiene vari campi.

157
00:11:17,620 --> 00:11:19,050
Qui, nell'esercizio,

158
00:11:19,050 --> 00:11:23,355
introdurremo solo due campi nel documento piatto,

159
00:11:23,355 --> 00:11:25,370
il nome e la descrizione.

160
00:11:25,370 --> 00:11:27,010
Nella prossima lezione,

161
00:11:27,010 --> 00:11:32,330
introdurremo i campi rimanenti per il DishSchema.

162
00:11:32,330 --> 00:11:33,680
Ora, quindi il nome,

163
00:11:33,680 --> 00:11:35,440
come in questo caso,

164
00:11:35,440 --> 00:11:36,765
è della stringa di tipo.

165
00:11:36,765 --> 00:11:39,450
Possiamo anche specificare che questo è un campo obbligatorio,

166
00:11:39,450 --> 00:11:43,360
il che significa che ogni documento dovrebbe contenere il campo nome.

167
00:11:43,360 --> 00:11:46,385
Possiamo anche specificare che il campo nome è univoco, il

168
00:11:46,385 --> 00:11:53,215
che significa che nessun documento può avere esattamente lo stesso valore del nome nel documento.

169
00:11:53,215 --> 00:11:55,980
Quindi, questo assicura che ogni documento avrà

170
00:11:55,980 --> 00:12:01,300
un campo nome univoco in esso e un campo di descrizione,

171
00:12:01,300 --> 00:12:03,115
che è di nuovo della stringa di tipo,

172
00:12:03,115 --> 00:12:06,460
ma anche specificato come richiesto.

173
00:12:06,460 --> 00:12:10,010
Ora, come abbiamo visto nell'esempio,

174
00:12:10,010 --> 00:12:15,750
un documento piatto contiene più commenti racchiusi all'interno del documento.

175
00:12:15,750 --> 00:12:20,920
Ora, in Mongoose, questo è supportato attraverso l'uso di sottodocumenti.

176
00:12:20,920 --> 00:12:24,230
Quindi, se si definisce uno schema in precedenza,

177
00:12:24,230 --> 00:12:27,345
così per esempio, abbiamo già definito un CommentSchema qui,

178
00:12:27,345 --> 00:12:33,370
è anche possibile definire un campo in un altro schema

179
00:12:33,370 --> 00:12:36,240
che si definisce e quindi specificare che tale campo sarà

180
00:12:36,240 --> 00:12:39,520
del tipo dello schema precedente che avete definito.

181
00:12:39,520 --> 00:12:40,960
Quindi, in questo caso,

182
00:12:40,960 --> 00:12:44,360
il campo dei commenti, lo sto definendo come un array,

183
00:12:44,360 --> 00:12:51,545
quindi vedi l'uso di un tipo di array nello schema che stai definendo qui,

184
00:12:51,545 --> 00:12:55,110
e quindi array del tipo CommentSchema.

185
00:12:55,110 --> 00:13:00,725
Quindi, questa è una serie di commenti che saranno inclusi in ogni documento piatto.

186
00:13:00,725 --> 00:13:02,590
Quindi, in tal modo, è possibile avere

187
00:13:02,590 --> 00:13:11,640
più di un documento secondario di commento racchiuso all'interno di un documento piatto.

188
00:13:11,640 --> 00:13:16,080
Quindi, definendo la struttura in questo modo ci permette di supportare

189
00:13:16,080 --> 00:13:20,950
la corrispondente struttura stringa JSON che abbiamo definito

190
00:13:20,950 --> 00:13:26,470
per un documento piatto o che abbiamo visto nell'esempio precedente.

191
00:13:26,470 --> 00:13:30,145
Ora, una volta definito lo schema,

192
00:13:30,145 --> 00:13:33,695
per fare uso di questo nella nostra applicazione,

193
00:13:33,695 --> 00:13:38,600
abbiamo bisogno di creare un modello da quello schema che abbiamo appena definito.

194
00:13:38,600 --> 00:13:40,640
Quindi, all'interno della nostra applicazione,

195
00:13:40,640 --> 00:13:45,320
definiremo un modello Mongoose e specificare che il modello

196
00:13:45,320 --> 00:13:51,085
è fuori dal tipo dishSchema in questo esempio.

197
00:13:51,085 --> 00:13:54,830
Non solo, darai anche un nome al modello qui.

198
00:13:54,830 --> 00:13:57,100
Quindi, quando si dà un nome al modello qui,

199
00:13:57,100 --> 00:14:00,000
stiamo specificando il nome come piatto.

200
00:14:00,000 --> 00:14:03,860
Ora, quando si utilizza questo modello piatto nella

201
00:14:03,860 --> 00:14:07,870
nostra applicazione nodo in cui stiamo facendo uso di Mongoose,

202
00:14:07,870 --> 00:14:15,280
allora questo sarà trasformato e mappato in una raccolta nel mio database MongoDB.

203
00:14:15,280 --> 00:14:18,885
La collezione stessa sarà nominata come piatti.

204
00:14:18,885 --> 00:14:23,355
Quindi, Mongoose sa automaticamente che quando si specifica un nome qui,

205
00:14:23,355 --> 00:14:27,990
costruirà automaticamente il plurale

206
00:14:27,990 --> 00:14:31,635
di quel nome e quindi darà alla raccolta il nome,

207
00:14:31,635 --> 00:14:37,160
che è il plurale del nome del modello specificato in questo esempio.

208
00:14:37,160 --> 00:14:39,400
Quindi, quando dico piatto qui,

209
00:14:39,400 --> 00:14:42,620
Mongoose automaticamente lo mapperà

210
00:14:42,620 --> 00:14:46,365
nella raccolta di piatti nel database MongoDB.

211
00:14:46,365 --> 00:14:53,385
Come fa a sapere come convertire questo nome singolare in un plurale?

212
00:14:53,385 --> 00:14:56,750
Mongoose ha automaticamente un meccanismo integrato che gli

213
00:14:56,750 --> 00:15:01,795
permette di costruire i plurali di parole inglesi standard.

214
00:15:01,795 --> 00:15:02,965
Quindi, se dici piatto,

215
00:15:02,965 --> 00:15:04,170
costruirà piatti.

216
00:15:04,170 --> 00:15:08,880
Se dici leader, costruirà il plurale di esso come leader, e così via.

217
00:15:08,880 --> 00:15:13,250
Quindi, questo è già integrato nel modulo nodo Mongoose.

218
00:15:13,250 --> 00:15:17,585
Quindi, questo è il motivo per cui quando lo specifico come tipo di modello di piatto,

219
00:15:17,585 --> 00:15:24,050
Mongoose costruirà la collezione di piatti nel mio database MongoDB,

220
00:15:24,050 --> 00:15:27,155
e quindi quella raccolta di piatti memorizzerà

221
00:15:27,155 --> 00:15:33,050
i vari documenti del tipo di piatto lì dentro.

222
00:15:33,050 --> 00:15:35,780
Una volta che abbiamo creato che, in genere,

223
00:15:35,780 --> 00:15:38,150
quando dichiariamo modelli nella nostra applicazione,

224
00:15:38,150 --> 00:15:43,780
vorremmo memorizzarli in una sottocartella denominata modelli, solo per comodità.

225
00:15:43,780 --> 00:15:44,900
Non è necessario farlo,

226
00:15:44,900 --> 00:15:47,320
ma solo per organizzare l'applicazione,

227
00:15:47,320 --> 00:15:50,635
normalmente lo memorizzeremmo in una cartella denominata modelli.

228
00:15:50,635 --> 00:15:55,010
Quindi lo schema e il modello sarebbero

229
00:15:55,010 --> 00:15:59,470
definiti in un file come questo come si vede nell'esempio qui,

230
00:15:59,470 --> 00:16:05,230
questo chiamato dishes.js, e quindi questo verrebbe esportato perché questo è un modulo nodo.

231
00:16:05,230 --> 00:16:10,970
Questo verrà esportato da questo file in modo che possa essere incluso nell'applicazione nodo,

232
00:16:10,970 --> 00:16:13,100
dove faremo uso di

233
00:16:13,100 --> 00:16:16,620
questo schema e del modello che abbiamo appena definito qui.

234
00:16:16,620 --> 00:16:20,540
Con questa rapida comprensione dello schema e del modello e il

235
00:16:20,540 --> 00:16:26,370
suo uso nella definizione della struttura di un documento che memorizziamo in un MongoDB,

236
00:16:26,370 --> 00:16:33,510
torniamo indietro e capiamo un po 'di più su ciò che Mongoose ci fornisce.

237
00:16:33,510 --> 00:16:39,965
Inoltre, Mongoose ci permette di stabilire la connessione con il server MongoDB.

238
00:16:39,965 --> 00:16:43,070
Mangusta utilizza internamente

239
00:16:43,070 --> 00:16:46,495
il driver MongoDB che avevamo usato nell'esercizio precedente.

240
00:16:46,495 --> 00:16:49,745
Quindi, Mongoose dipende dal driver MongoDB, quindi,

241
00:16:49,745 --> 00:16:53,824
il che significa che dall'applicazione del nodo basata su Mongoose,

242
00:16:53,824 --> 00:16:56,960
è possibile utilizzare tutti i metodi che sono già

243
00:16:56,960 --> 00:17:01,040
disponibili dal driver MongoDB anche se si sceglie di farlo,

244
00:17:01,040 --> 00:17:05,390
ma Mongoose stesso ha una propria raccolta di metodi che

245
00:17:05,390 --> 00:17:09,940
possiamo rendere uso di per interagire con il database MongoDB,

246
00:17:09,940 --> 00:17:13,645
come vedremo nell'esercizio che segue.

247
00:17:13,645 --> 00:17:19,040
Permettetemi di mostrarvi brevemente come stabilire una connessione al database,

248
00:17:19,040 --> 00:17:21,590
e lo farete nell'esercizio che segue.

249
00:17:21,590 --> 00:17:25,280
Quindi, proprio come abbiamo dichiarato l'URL nel caso

250
00:17:25,280 --> 00:17:29,160
dell'applicazione nodo MongoDB nella lezione precedente,

251
00:17:29,160 --> 00:17:32,630
continueremo a dichiarare l'URL per la nostra applicazione.

252
00:17:32,630 --> 00:17:36,965
Quindi useremo il metodo di connessione Mongoose

253
00:17:36,965 --> 00:17:40,180
e fornire l'URL per il metodo di connessione Mongoose,

254
00:17:40,180 --> 00:17:44,000
e questo stabilirà la connessione al database.

255
00:17:44,000 --> 00:17:48,590
Con questa rapida comprensione di Mongoose e quale ruolo

256
00:17:48,590 --> 00:17:53,485
gioca Mongoose nel supportare l'inserimento strutturato

257
00:17:53,485 --> 00:17:58,985
, l'archiviazione e il recupero di documenti dal nostro MongoDB,

258
00:17:58,985 --> 00:18:02,180
passiamo all'esercizio in cui

259
00:18:02,180 --> 00:18:07,920
otterremo qualche esperienza pratica usando il modulo Mongoose.