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:
...
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.
...