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:
[StringProperty(MaximumLength=60)] public virtual string FirstName { get; set; } [StringProperty(MaximumLength=60, IsNullable=false)] public virtual string Surname { get; set; } // *** A REFERENCE PROPERTY REFERENCING A 'Location' INSTANCE *** 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.