В предыдущем уроке
мы узнали о драйвере MongoDB.
Это позволяет нашему узловому приложению взаимодействовать с сервером MongoDB,
а также хранить и извлекать документы с сервера MongoDB.
Мы также видели, что драйвер MongoDB предоставляет нам
много методов, которые позволяют нам создавать коллекции в базе данных,
добавлять документы в коллекции,
а затем выполнять различные операции над документами в коллекции.
Теперь, когда документы хранятся в базе данных,
драйвер MongoDB сам не накладывает структуры на документы.
Если нам нужно иметь конкретную структуру для документов и применять эту структуру,
то нам нужно использовать модуль узла Mongoose, который позволяет нам определить
схему и структуру для наших документов, которые хранятся в нашей базе данных MongoDB,
и строго применяет структуру.
Давайте рассмотрим более подробную информацию в этой лекции и упражнения, которые следуют за этой лекцией.
Как мы уже узнали,
MongoDB хранит данные в коллекциях в базе данных.
Эти коллекции состоят из коллекции документов.
Сами документы, хранящиеся в
базе данных MongoDB, не имеют конкретной структуры, наложенной на документ.
Любой документ может быть сохранен в любой коллекции.
MongoDB полагается на разработчика для обеспечения структуры на документах
и дает полную ответственность разработчику, чтобы убедиться, что документы
правильной структуры добавляются и поддерживаются в различных коллекциях.
Теперь это очень легко нарушить.
Например, даже если вы можете начать с предположения
, что конкретное соединение будет иметь документы определенной структуры,
вы можете легко вставить документы, которые не обязательно соответствуют структуре.
Если вы очень уверены, что структура документов в
коллекции всегда имеет указанную структуру,
и всегда будет иметь конкретный набор полей,
то сам MongoDB не навязывает, что ни
драйвер узла MongoDB, который мы видели в предыдущем уроке.
Здесь нам понадобится более формальный способ наложения
структуры на документы, которые хранятся в коллекции в базе данных MongoDB.
Вот где модуль узла Mongoose приходит к нам на помощь.
Модуль узла Mongoose накладывает
стандартизованную структуру для документов, которые хранятся в определенной коллекции.
Поэтому мы часто слышим, как люди называют это Mongoose ODM.
Сама ODM интерпретируется некоторыми людьми
как означающая модель объектных данных или иногда называется сопоставлением объектных документов,
или некоторые люди ссылаются на нее как ORM или объектно-реляционное сопоставление.
Теперь, когда мы говорим о реляционных, которые применяются гораздо больше к реляционным базам данных,
но затем с базами данных SQL нам нужно явно объект
реляционного сопоставления, который должен быть помещен между базой данных и самим нашим приложением.
Потому что в приложении мы будем смотреть на
объекты, но их хранение в базе данных SQL будет в виде записей,
и поэтому вам нужно явное сопоставление.
Как мы видели с базой данных NoSQL,
это явно не требовалось.
Но если вам нужно наложить структуру на ваши документы, которые хранятся в коллекции,
то использование Mongoose для навязывания этой структуры очень, очень полезно.
То, как Mongoose обходит
навязывание структуры на документы, - это использование схемы.
Схема, определяет структуру их документов.
Давайте поговорим об этом чуть более подробно.
Итак, что именно такое схема мангуста,
и что она приносит в таблицу?
Схема Mongoose, подразумевает структуру
на данных, которые хранятся в документе в вашей базе данных.
Таким образом, он определяет все поля вашего документа,
а также определяет типы полей,
а также может предоставить нам
дополнительные функции, которые могут включить проверку на этих полях.
Так, например, различные типы схем, которые поддерживаются в Mongoose включают: String,
Number, Date, Buffer, Boolean,
Mixed, Object ID и Array.
В частности, мы рассмотрим номер строки,
и дату, и логическое в упражнении, которое следует.
Мы рассмотрим некоторые из других в последующих упражнениях.
В частности, обратите внимание на использование типа схемы массива.
Таким образом, тип схемы массива позволит вам
создать массив вложенных документов внутри документа.
Я поговорю об этом через некоторое время.
После определения схемы, схема
затем используется в Mongoose для создания функции модели,
и это то, что позволяет вам определить структуру для ваших документов в базе данных.
Сами схемы могут иметь вложенность.
Таким образом, это означает, что вы можете иметь вложенный документ, который заключен внутри документа.
Поддокументы, как правило, удовлетворяются
либо путем указания дополнительной схемы,
а затем определения одного из полей схемы, чтобы быть вне типа другой схемы.
Или вы даже можете пойти с массивом
другого типа схемы во второй схеме, которую вы определяете.
Давайте посмотрим на пример, чтобы прояснить некоторые из них более подробно.
Этот пример будет из упражнения, которое вы будете делать сразу после этой лекции.
Прежде чем я смогу поговорить о схемах и моделях в Mongoose,
давайте поймем, почему это нужно.
Если вы взяли предыдущий угловой,
ионный, или родной сценарий курса,
вы видели, что мы представляем
различные данные, которые мы используем в наших приложениях в виде строк JSON.
Итак, в нашем приложении мы определяем коллекцию, называемую блюдами.
В коллекции блюд,
каждое блюдо будет содержать определенный набор свойств, определенных в виде строки JSON,
как вы видите в этом примере.
Таким образом, блюда представляют собой массив типа блюда,
и каждое блюдо само будет содержать имя,
изображение, категорию
, этикетку и так далее.
Кроме того, внутри самого документа блюда
у вас будут комментарии, которые хранятся как массив снова, -
документы JSON, которые содержат определенные поля шаг.
Таким образом, каждый комментарий, например,
содержит автора комментария рейтинга и поле даты, как вы видите в этом примере.
Таким образом, вы видите, что есть четкая структура для
каждого документа, который определяет блюдо, которое хранится в нашей базе данных.
Несколько блюд, очевидно, будут храниться в виде коллекции в нашей базе данных,
и могут быть сгруппированы вместе и отправлены в виде массива
блюд для нашего клиентского приложения, которое будет использоваться.
Теперь, когда мы поняли, как это определено, теперь,
как это относится к схеме Мангуста и модели, которую мы определяем в Мангусте?
Теперь обратите внимание на структуру типичного документа блюда здесь.
Таким образом, это можно легко отобразить в документе MongoDB в коллекции,
возможно, названном коллекцией блюд.
Таким образом, мы видим, что в самом документе есть четкая структура.
Теперь, как мы зеркалируем это в схеме в нашем приложении Mongoose?
Как вы узнаете в упражнении,
мы увидим, что мы будем определять схемы в Mongoose.
Таким образом, схема определяется как схема Mongoose здесь.
В качестве примера здесь показана схема комментария.
CommentSchema, как вы можете видеть,
содержит три различных поля: рейтинг, комментарий
и поле автора,
а также метки времени здесь.
Отметки времени позволяют иметь два различных поля в
документе: созданные в поле и обновленные в поле,
оба из которых являются временными метками, хранящимися в виде строки даты ISO в документе.
Теперь сам рейтинг будет целочисленным значением.
Таким образом, в терминологии Mongoose,
он будет храниться как число,
тип будет числом.
Можно даже указать минимальное и максимальное значения.
Вы также можете указать, что это конкретное поле является обязательным, а
это означает, что каждый документ типа комментария должен содержать поле оценки.
Аналогично, вы также можете определить поле комментария,
которое имеет тип строки.
Таким образом, очевидно, комментарий - это не что иное, как строка, содержащая некоторую информацию,
и это также может быть определено как обязательное поле,
что означает, что каждый документ должен содержать комментарий,
а также поле автора,
которое также имеет строку типа.
Таким образом, вы видите это, определяя эту схему в этом формате.
Как мы узнали в обсуждении немного ранее,
схема определяется с помощью различных типов, которые мы имеем в нашем приложении Mongoose.
Итак, в схеме, опять же,
вы видите здесь три разных поля:
рейтинг, комментарий и автор,
и каждое из которых имеет определенный тип,
и тогда является ли это обязательным или нет.
Таким образом, вы навязываете строгую структуру
документов комментариев, которые будут храниться в вашем приложении.
Теперь, когда мы определили схему комментария, мы можем тогда,
как вы заметили из примера типа данных, которые мы требуем в нашем приложении,
у нас есть сам документ блюдо.
Документ блюдо содержит различные поля.
Здесь, в упражнении,
мы вначале введем только два поля в документ блюдо
, название и описание.
В следующем уроке
мы представим оставшиеся поля для DishSchema.
Теперь, так имя,
как и в этом случае,
имеет строку типа.
Мы также можем указать, что это обязательное поле,
что означает, что каждый документ должен содержать поле имени.
Мы также можем указать, что поле name является уникальным,
что означает, что ни один документ не может иметь точно такое же значение имени в документе.
Таким образом, это гарантирует, что каждый документ будет иметь
уникальное поле имени в нем и поле описания,
которое снова является строкой типа,
но также указано по мере необходимости.
Теперь, как мы видели в примере,
документ блюдо содержит несколько комментариев, вложенных внутри документа.
Теперь, в Mongoose, это поддерживается путем использования поддокументов.
Таким образом, если вы определяете схему ранее,
например, мы уже определили CommentSchema здесь,
вы также можете определить поле в другой схеме, которую вы определяете, а
затем указать, что это поле будет
иметь тип предыдущей схемы, которую вы определили.
Итак, в этом случае
поле комментариев я определяю его как массив,
поэтому вы видите использование типа массива в вашей схеме, которую вы определяете здесь,
а затем массив типа CommentSchema.
Таким образом, это массив комментариев, которые будут включены в каждый документ блюдо.
Таким образом, вы можете иметь
более чем один вложенный документ комментария, заключенный внутри документа блюдо.
Таким образом, определение структуры, как это позволяет нам поддерживать
соответствующую структуру строки JSON, которую мы определили
для документа блюда или что мы видели в примере ранее.
Теперь, как только мы определим схему,
чтобы использовать это в нашем приложении,
нам нужно создать модель из этой схемы, которую мы только что определили.
Таким образом, в нашем приложении,
мы определим модель Mongoose и укажите,
что модель вне типа DishSchema в этом примере.
Мало того, что вы также дадите название модели здесь.
Итак, когда вы даете имя модели здесь,
мы указываем имя как блюдо.
Теперь, когда вы используете эту модель блюда в
нашем приложении узла, где мы используем Mongoose,
то это будет преобразовано и отображено в коллекцию в моей базе данных MongoDB.
Сама коллекция будет называться блюдами.
Таким образом, Mongoose автоматически знает, что когда вы укажете имя здесь,
он автоматически создаст
множественное число этого имени, а затем даст коллекции имя,
которое является множественным числом имени модели, которое вы указываете в этом примере.
Итак, когда я говорю блюдо здесь,
то Mongoose автоматически сопоставит это
в коллекцию блюд в базе данных MongoDB.
Как он знает, как преобразовать это единственное имя во множественное число?
Mongoose автоматически имеет встроенный механизм, который
позволяет ему построить множество стандартных английских слов.
Так что, если вы скажете блюдо,
он будет строить блюда.
Если вы говорите лидер, он построит множественное число его как лидеров и так далее.
Таким образом, это уже встроено в модуль узла Mongoose.
Поэтому, когда я указываю это как тип модели блюда,
то Mongoose построит коллекцию блюд в моей базе данных MongoDB,
а затем эта коллекция блюд будет хранить
различные документы типа блюда там.
После того, как мы создали, что, как правило,
когда мы объявляем модели в нашем приложении,
мы будем хранить их в подпапке с именем модели, просто для удобства.
Вам не нужно это делать,
но просто для того, чтобы организовать ваше приложение,
мы обычно храним его в папке с именем models.
Затем схема и модель будут
определены в файле, подобном этому, как вы видите в примере здесь,
это называется dishes.js, а затем это будет экспортировано, потому что это модуль узла.
Это будет экспортировано из этого файла, так что он может быть включен в приложение узла,
где мы собираемся использовать
эту схему и модель, которую мы только что определили здесь.
С этим быстрым пониманием схемы и модели и
ее использования в определении структуры для документа, который мы храним в MongoDB,
давайте вернемся и поймем немного больше о том, что Mongoose предоставляет для нас.
Кроме того, Mongoose позволяет установить соединение с сервером MongoDB.
Mongoose внутренне использовать
драйвер MongoDB, который мы использовали в предыдущем упражнении.
Таким образом, Mongoose зависит от драйвера MongoDB, поэтому,
что означает, что из вашего приложения на основе Mongoose
вы можете использовать все методы, которые уже
доступны из драйвера MongoDB, также если вы решите,
но сам Mongoose имеет свою собственную коллекцию методов, которые мы
можем сделать использование для взаимодействия с базой данных MongoDB,
как мы увидим в упражнении, которое следует.
Позвольте мне кратко показать вам, как мы
установим соединение с базой данных, и вы сделаете это в следующем упражнении.
Таким образом, так же, как мы объявили URL в случае
приложения узла MongoDB в предыдущем уроке,
мы все равно объявим URL для нашего приложения.
Затем мы будем использовать метод Mongoose connect
и поставим URL для метода Mongoose connect,
и это установит соединение с базой данных.
С этим быстрым пониманием Mongoose и какую роль Mongoose
играет в поддержке структурированной вставки
, хранения и извлечения документов из нашего Mongoob,
давайте перейдем к упражнению, где мы
получим практический опыт с использованием модуля Mongoose.