Associating objects
When objects are first created, they are little islands of information that is not associated to any other object in the environment. To define additional meaning we associate objects together.
Consider this simple model (that appeared in the architecture video). Also, have a look at the section on lazy loading in the overview.
Consider this simple model (that appeared in the architecture video). Also, have a look at the section on lazy loading in the overview.
We have an association line running between RoomDefinition and DoorTrigger. This line defines two roles; the "TheRoom" and the "Triggers".
The SQLINQ Generator will create a new attribute on the RoomDefinition class called "Triggers". This is a list of all DoorTrigger instances associated to the RoomDefinition. It also creates a new attribute on DoorTrigger called "TheRoom" that contains a reference to the RoomDefinition.
To associate a DoorTrigger, such as, theTrigger, to a specific RoomDefinition, such as, myDefinition, you say:
myDefinition.Triggers.Add( theTrigger );
theTrigger.TheRoom = myDefinition;
When moving a DoorTrigger from one RoomDefinition to another you say:
myOldDefinition.Triggers.Remove( theTrigger );
myNewDefifinition.Triggers.Add( theTrigger );
theTrigger.TheRoom = myNewDefinition;
To associate and properly maintain the association, you must manually move the object from one item from one list to another. In the example above, by failing to remove TheTrigger from myOldDefinition, you run the risk of making erroneous decisions based the presence of a Trigger in the wrong list in memory.
From a database/persistence perspective, to properly persist the association, you need to assign the correct parent/master before saving changes made to theTrigger.
theTrigger.TheRoom = myNewDefinition;
Is what is required to properly persist the data. If you look at Trigger's Save method, it looks like this, with the Green line showing how it decides how to save the association. It actually traces back to TheRoom to figure out the OID that is assigned.
public override ValidationResult Save() {
ValidationResult MESSAGES = Validate();
if ( MESSAGES.isError ) {
return MESSAGES;
}
// Construct a table and assign all the attributes
TriggerStateTable TABLE = new TriggerStateTable {
OID = this.OID , // Identifier
SubType = cSubType , // Subtype Classifier
TriggerName = this.TriggerName , // Regular attribute
State = this.State , // Regular attribute
SceneName = this.SceneName , // Regular attribute
DoorType = (int) this.DoorType , // Enumeration from 'DoorTypes'
TheRoomOID = this.TheRoom.OID , // Master Reference to 'RoomDefinition'
};
// Write instance to database
bool RESULT = Repository.Save( TABLE , this );
if ( ! RESULT ) {
MESSAGES.Add(MessageType.Error, "Instance ' #" + OID + " failed to be written to database.", this.GetType().FullName );
}
return MESSAGES;
}
The SQLINQ Generator will create a new attribute on the RoomDefinition class called "Triggers". This is a list of all DoorTrigger instances associated to the RoomDefinition. It also creates a new attribute on DoorTrigger called "TheRoom" that contains a reference to the RoomDefinition.
To associate a DoorTrigger, such as, theTrigger, to a specific RoomDefinition, such as, myDefinition, you say:
myDefinition.Triggers.Add( theTrigger );
theTrigger.TheRoom = myDefinition;
When moving a DoorTrigger from one RoomDefinition to another you say:
myOldDefinition.Triggers.Remove( theTrigger );
myNewDefifinition.Triggers.Add( theTrigger );
theTrigger.TheRoom = myNewDefinition;
To associate and properly maintain the association, you must manually move the object from one item from one list to another. In the example above, by failing to remove TheTrigger from myOldDefinition, you run the risk of making erroneous decisions based the presence of a Trigger in the wrong list in memory.
From a database/persistence perspective, to properly persist the association, you need to assign the correct parent/master before saving changes made to theTrigger.
theTrigger.TheRoom = myNewDefinition;
Is what is required to properly persist the data. If you look at Trigger's Save method, it looks like this, with the Green line showing how it decides how to save the association. It actually traces back to TheRoom to figure out the OID that is assigned.
public override ValidationResult Save() {
ValidationResult MESSAGES = Validate();
if ( MESSAGES.isError ) {
return MESSAGES;
}
// Construct a table and assign all the attributes
TriggerStateTable TABLE = new TriggerStateTable {
OID = this.OID , // Identifier
SubType = cSubType , // Subtype Classifier
TriggerName = this.TriggerName , // Regular attribute
State = this.State , // Regular attribute
SceneName = this.SceneName , // Regular attribute
DoorType = (int) this.DoorType , // Enumeration from 'DoorTypes'
TheRoomOID = this.TheRoom.OID , // Master Reference to 'RoomDefinition'
};
// Write instance to database
bool RESULT = Repository.Save( TABLE , this );
if ( ! RESULT ) {
MESSAGES.Add(MessageType.Error, "Instance ' #" + OID + " failed to be written to database.", this.GetType().FullName );
}
return MESSAGES;
}