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
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
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.
What about m-n relations?
Here is sample code: Junction objects.