PhoneBook.Domain -- relationships

The Location class used as example so far has no property referencing other domain object classes. In domain terms: a Location instance does not know who lives there.

This knowledge works the other way around: It is the Person instance that knows where it lives, because it includes a reference property of type Location. Here are Person's properties:

    public virtual string FirstName { get; set; }

    [StringProperty(MaximumLength=60, IsNullable=false)]
    public virtual string Surname { get; set; }

    public virtual Location Location { get; set; }
    [DBBidirectionalRelation("Person", SortExpression="CountryCode, AreaCode, Number, Extension")]    
    public virtual ObjectList<PhoneNumber> PhoneNumbers { get; set; }

This, of course, mimics a foreign key in the database: the Location column in the Person table will contain the primary key for the Location instance where that Person instance lives.

Note that the reference property Location Location is not attributed in any way. The naked .NET-declaration is sufficient to let re-store know how this reference property is supposed to work.

Such a naked declaration, and the whole scheme of relating domain objects, is called a unidirectional relationship. The Person object points to the Location object, but not the other way around.

This is in contrast to the declaration of the PhoneNumbers property. Note that it is attributed with the [ DBBidirectionalRelation ] attribute. What's more, the property can store more than one PhoneNumber instance, because it is an ObjectList typed PhoneNumber.

If you look at the declaration for the PhoneNumber class, you will notice, that its Person Person declaration is also attributed with [ DBBidirectionalRelation ].

This technology is called bidirectional relationships and is an important and powerful re-store feature.

It provides all sorts of automation and notification between the parties in the relation.

See next
What about m-n relations?

Here is sample code: Junction objects.