MongoDB: Как определить динамический объект в моем собственном классе домена?

Question

Новое для MongoDB. Настройте веб-проект C# в VS 2013.

Необходимо вставить данные в качестве документа в MongoDB. Количество Key-Value пара каждый раз может быть разным.

Например,
document 1: Id is "1", данные одна пара ключ-значение: "order":"shoes"
document 2: Id is "2", данные представляют собой 3-пара ключ-значение: "order":"shoes", "package":"big", "country":"Norway"

В этом "Getting Started" говорит, потому что это так много проще работать со своими собственными доменами, этот быстрый запуск предполагает, что вы собираетесь это сделать. предлагает сделать наш собственный класс, как:

public class Entity 
{ 
    public ObjectId Id { get; set; } 
    public string Name { get; set; } 
} 

затем использовать его как:

var entity = new Entity { Name = "Tom" }; 
... 
entity.Name = "Dick"; 
collection.Save(entity); 

Ну, побеждает идея не фиксируемых колонн, не так ли?

Итак, я думаю, что модель BsonDocument - это модель для использования и есть ли хорошие образцы для начинающих?

Спасибо.

Answer 1

Я поражен, как часто эта тема приходит ... По сути, это больше «статически типизированных ограничения языка», чем вопрос MongoDB:

Schemaless не означает, что у вас нет какой-либо схема сама по себе, это в основном означает, что вам не нужно сообщать базе данных перед началом, что вы собираетесь хранить. Это в основном «код первый» - код просто записывается в базу данных, как в RAM, при всей гибкости.

Конечно, типичное приложение будет иметь какую-то повторяющуюся структуру данных, некоторые классы, некоторую объектно-ориентированную парадигму так или иначе. Это также верно для индексов: индексы (обычно) «статические» в том смысле, что вы do должны сообщить mongodb о том, в каком поле индексировать вверх.

Однако есть также случай использования, когда вы не знаете, что хранить. Если ваши данные действительно непредсказуемы, имеет смысл подумать «сначала код»: что бы вы сделали на C#? Вы бы использовали BsonDocument? Возможно нет. Возможно, встроенный Dictionary выполняет трюк, например.

public class Product { 
    public ObjectId Id {get;set;} 
    public decimal Price {get;set;} 
    public Dictionary<string, string> Attributes {get;set;} 
    // ... 
} 

Это решение также может работать с multikeys to simulate a large number of indexes делать запросы по атрибутам достаточно быстро (хотя отсутствие статической типизации делает интервальные запросы каверзные). См.

Это действительно зависит от ваших потребностей. Если вы хотите иметь вложенные объекты и статическую типизацию, все становится намного сложнее, чем это. Опять же, потребителю такой структуры данных (т. Е. Интерфейсу или клиентскому приложению) часто приходится делать предположения, которые облегчают переваривание этой информации, поэтому часто невозможно сделать этот тип безопасным в любом случае.

Другие варианты включают, действительно, использование BsonDocument, которое я считаю слишком инвазивным в том смысле, что вы делаете ваши бизнес-модели зависимыми от реализации драйвера базы данных; или используя общий базовый класс, например ProductAttributes, который может быть расширен такими классами, как ProductAttributesShoes и т. д. Этот вопрос действительно вращается вокруг всего дизайна системы - знаете ли вы свойства во время компиляции? У вас есть выпадающие списки для значений свойств в вашем интерфейсе? Откуда они?

Если вы хотите что-то многоразовое и гибкое, вы можете просто использовать библиотеку JSON, сериализовать объект в строку и сохранить его в базе данных. В любом случае взаимодействие с такими объектами будет уродливым со стороны C#, потому что они не статически типизированы.