This one had me scratching my head for days, and my eventual solution is far from elegant, and I would love to discover a nicer method.
The problem is I could not find any way to reference a Domain Property from a relationship within code (.tt generation or validation code) from the object sourcing (or targeting) the relationship.
In my case, I have nested relationships contained within BaseCollection *sigh, I know, legacy* inherited objects. There are other reasons we have kept this, despite wanting to refactor to List, but I can't be bothered going into that here [edit - thank God, we have finally got time to refactor this away!]. It's something I may address in my DSL project (based on the framework we are using here) when I publish it.
In some cases an object can contain more than one type of contained object, and I want to maintain each list of type separately. In this case, I just use a List object property to store the other lists not being addressed by the BaseCollection.
To this ends, when we model this in our DSL, we have a 'IsMainEntity' boolean on the relationship, not either of the objects (as they have 0..* cardinality and may be referenced by other objects, so this boolean has to be a property of the relationship).
My next task was to ensure through validation, that there was only one "IsMainEntity" relationship for parent.
Whilst parent and child objects are easy to access through the generated object model as LinkElementCollections, relationships are not so easily accessed, either as a collection, or as a property on the source or target object.
Eventually, after hours of staring at the watch and immediate windows (and yelling at the non-public members for not being public) I discovered the DomainRoleInfo object, sitting in my target collection.SourceDomainRole.DomainRelationship, that the msdn rather concisely states "Represents a role of a domain relationship".
We can retrieve this object and query it for links (relationships) in the model based on an object (or modelElement) on the dsl model.
Using this, I crafted this rather clunky code for my validation block:
found = false;
//Build elements list to pass as an array to the violation, so the correct objects can be highlighted on the model
elements = new List();
elements.Add(this);
foreach (DomainRoleInfo info in Entity1s.SourceDomainRole.DomainRelationship.DomainRoles)
{
if (info.Name.Equals("Entity2"))
{
foreach (Entity1ReferencesEntity2 e12e2 in info.GetElementLinks(this))
{
if (e12e2.IsMainEntity)
{
elements.Add(e12e2);
if (found)
{
//Log the Error
}
else
found = true;
}
}
info.GetElementLinks(this);
}
}
I have yet to craft the class generation .tt file, but I need a different code depending on whether IsMainEntity is set on a the relationship, so I will probably have to pass the source and target elements to a method, have it loop through the ElementLinks of the source object to find the appropriate DomainRoleInfo (accessable only by index, not name) and return a true if the MainEntity boolean is set. Not very pleasant, but doable.