7

I'm new to MongoDb, but i am aware that speaking about relation in a document db is something that smell. Anyway i'm trying it just to understand if it fits my needs and where are its limits.

I've just a simple c# entity in my domain that is:

class Person
{
    public int Id { get; set; }

    public string Name { get; set; }

    public string Surname { get; set; }

    public ICollection<Person> Friends { get; set; }
}

And i just want that the serialization process makes that collection a sort of list of 

["...api/persons/1", "...api/persons/2", ...]

is it possible in some way?

Matteo Fontana
  • 73
  • 1
  • 1
  • 4
  • have a look at the [MongoDB.Entities](https://github.com/dj-nitehawk/MongoDB.Entities) wrapper library. it can handle one-to-one, one-to-many and many-to-many relationships quite effortlessly. – Dĵ ΝιΓΞΗΛψΚ May 08 '19 at 17:37
  • @DĵΝιΓΞΗΛψΚ Hi I used your lib for a while but recently I cannot find a way to let System.Text.Json to serialize your Many<> and One<> field. Any ways to serialize the Json? – user2617470 Nov 23 '21 at 10:46
  • @踩我的都死马 don't do it!!! you shouldn't be exposing your data entities to the presentation/ui layer. you should use DTOs and map to-and-from data entities only the exact data/info needed by the ui for a particular view/feature. it's also a very bad idea to serialize a Many property even if you could. for example, what if that property points to 1000 related entities? bad idea. if you need further help, pls create an issue on github with your exact use case. show me your data entities (simplified with only relevant properties) and the expected output. – Dĵ ΝιΓΞΗΛψΚ Nov 23 '21 at 16:08

1 Answers1

14

relation in a document db is something that smell

No, not at all. Sadly, that notion is popular, but there's nothing wrong with relations in non-relational databases. It's just a different approach to manage those relations.

But let's look at your model:

public ICollection<Person> Friends { get; set; }

As you have probably figured out, that would serialize a tree of documents:

{ "name" : "doe",  
  "firstName" : "john", 
  "friends" : [ 
      { "name" : "rogers", 
        "firstName" : "mike", 
        "friends" : [ {"name" : "myers", "firstName" : "lucy", ... },  
        ... ] },
 ... ] }

In other words, these would not serialize as relations, but as embedded documents.

Now the easiest and cleanest approach is to store relations if you want relations:

class Person {
    public ObjectId Id { get; set; }
    public string FirstName { get; set; }
    public List<ObjectId> FriendIds { get; set; }
}

That will require manually translating from your domain model to a database-compatible model, which begs the question why you want a domain model in the first place.

The problem with domain models is that they require a partially serialized graph in RAM. That seems convenient to work with from the .NET side, e.g. you could do something like

person.Friends.First().Friends.Where(p => p.Name == "Doe").Friends.Last...

But it's utterly unclear how to fetch all this from the database, because that simple one-line expression would probably require at least 4 round-trips to the database. While such a mapping can be implemented (transparent activation), it hides a lot important information from the programmer.

If you add modifications (and modification tracking) to the equation, things get very messy very quickly.

Also, the model looks like an m:n relation to me (a person can have many friends, and a person could be referenced as friends by many other persons, right?). For m:n relations, embedding lists of references might not be the best approach, but there are alternatives.

Community
  • 1
  • 1
mnemosyn
  • 45,391
  • 6
  • 76
  • 82