Question

I am using mongodb from C#.

I have an entity definition, and I want reference another entity from this one.
(Note the embed is not an option)

I know that I can insert a field with the other entity id in the first one. That is something like:

class Person
{
    public object Id { get; set; }
    public string Name { get; set; }
    public object Pet { get; set; }  // note here I have the pet Id and not the pet.
}


class Pet
{
    public object Id{get;set;}
    .....
}

Now, here I am inserting in my domain logic business some rare mechanics.

Then my question is: Is out there some practices that allow me hide this kind of issues to
my domain layer, I mean in my domain I just want have something like:

class Person
{
   public object Id { get; set; }
   public string Name {get; set; }
   public Pet Pet { get; set; }  // note here I have the pet.
}


class Pet
{
   public object Id{get;set;}
   .....
}

In my domain I want focus in the coding instead of the mechanics.

Answer 1

My recommendation would be not to use mongodb, which is a nosql aka document based db , as a relational db. The recommended way for modelling data in nosql is to treat each document as an aggregate root (http://lostechies.com/jimmybogard/2008/05/21/entities-value-objects-aggregates-and-roots/) i.e. making a distinction between entity and value object is very crucial Value objects should not have ids. In the mongodb tutorial below
http://www.codeproject.com/Articles/87757/MongoDB-and-C

Comments are value objects. So the main question is pet a value object and require an ID.
If it does not then remove ID from Pet class and embed pet inside Person class. If it requires an ID then keep ID field in Pet class , save it as its own document and store Pet ID in Person class. This is the recomended pattern for nosql data modelling.

A neat trick to evaluate if your data model suits nosql is to ask yourself does this document provide the complete information for a Person in the context ( a person who owns a pet) in one trip or document then usually you are using it incorrectly. Though for a different nosql database the following articles convey this concept very well

http://ayende.com/blog/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases
http://ayende.com/blog/4466/that-no-sql-thing-modeling-documents-in-a-document-database

Hope this helps.