MongoDB C# 驱动程序 - POCO 引用的序列化？

Question

I'm researching MongoDB at the moment. It's my understanding that the official C# driver can perform serialization and deserialization of POCOs . What I haven't found information on yet is how a reference between two objects is serialized. [I'm talking about something that would be represented as two seperate documents, with ID links, rather than embeded documents.

Can the serialization mechanism handle this kind of situation? (1):

class Thing {
    Guid Id {get; set;}
    string Name {get; set;}
    Thing RelatedThing {get; set;}
}

Or do we have to sacrifice some OOP, and do something like this? (2):

class Thing {
    Guid Id {get; set;}
    string Name {get; set;}
    Guid RelatedThing_ID {get; set;}
}

UPDATE:

Just a couple of related questions then...

a) If the serializer is able to handle situation (1). What is an example of how to do this without using embedding?

b) If using embedding, would it be possible to query across all 'Things' regardless of whether they were 'parents' or embedded elements? How would such a query look like?

Answer 1

The C# driver can handle serializing the class containing a reference to another instance of itself (1). However:

1. As you surmised, it will use embedding to represent this
2. There must be no circular paths in the object graph or a stack overflow will occur

If you want to store it as separate documents you will have to use your second class (2) and do multiple inserts.

Querying across multiple levels is not really possible when the object is stored as one large document with nested embedding. You might want to look at some alternatives like:

https://docs.mongodb.com/manual/applications/data-models-tree-structures/

Answer 2

Yes, That is completely possible.

One thing you must understand about MongoDB and most NoSQL solutions is that objects can be contained within other objects. In the case of MongoDB, it's basically, if you can create the object in JSON, then you can create the object in MongoDB.

In general, you should strive to have a "relatively" denormalized database structure. A little bit of duplicated data is ok as long as you're not updating it often.

Answer 3

I've encountered the same issue recently, and I usually steer away from them but... I'm thinking that this could be a good use for a significant numbering system deployed on the Id field.

class Thing {
string Id {get; set;}
string Name {get; set;}
string RelatedThing {get; set;}}

So, simplifying, if Id was something like "T00001" (or indeed T + GUID), you could easily get the set of things from Mongo by querying for something like Id starts with T , and setting up objects for them all (or just for the subset you know contains your reference, if it is a very large set).

You know/expect that RelatedThing to be a Thing , but it will just be a string when it comes back from Mongo. But if you've set up objects as above, you could effectively use the string as if it were an object reference (after all, that is what it really is, done kind of "manually").

Its a 'loose' way of doing it, but might be workable for you.

Can anyone see any pitfalls with that approach?

Answer 4

If you really want a reference to another document, you can use a DBRef . However there is limitation with references in MongoDB.

• you can only query by id on a ref
• when you get your Thing's document, you'll have to make a second query to get the associated RelatingThing's document as join doesn't exists in MongoDB.