Blizzard Architecture


Blizzard has the following characteristics:
  • Is a lightweight O/R Mapper
  • Can handle the following relationships:
    • One to many
    • One to many composition
    • Many to many
  • Objects are relation aware.


How does it work:

To avoid logical complexity Blizzard does only lazy loading:
  • Loads the main object in its simple form.
  • At the time of a call to a complex property, the call will be intercepted. It is at this moment that the associated object will be loaded from the database.
To make interception possible, Castle Dynamic Proxy is used


Relation Objects

The following illustration shows a standard call to a property:

Object2 obj2 = obj1.PropertyOfTypeObject2

R1.png

Now, this is how a call to a property looks like in Blizzard

R2.png


As you see, in Blizzard, objects are not connected directly. That means, they are always connected through relation objects. A relation object is an object encapsulating all the information regarding the relationship between two objects. In addition, a relation object would record the changes inflicted to the relationship between two objects. Later, these additional information will be used at the time of Database update (think of a broken relationship or a marked for deletion relationship).

The following illustration shows what the structure of such relation object is:

R3.png

A relation object or more accurately a Blizzard.Container.RelationInstance represents an instance of a relationship between two objects. In its heart it carries a Blizzard.Container.RelationDefinition object. A RelationDefinition contains non-instance information between two types rather than two objects. So there can only be one RelationDefinition object for two types involving a relationship. The information encapsulated in the RelationDefinition comes from the IMapper object.

At the same time because of this mechanism, the objects in Blizzard are relation aware. That means if there is a change to a relationship triggered from one side of the relationship. The other side of relationship is automatically aware of this change. for example imagine the following scenario:

Type A has a parent to child relationship with Type B. At the time that you assign an object of type A to the parent property of Type B, A is also aware of this relationship. that means that you can find the B object in the children list of A:


B b = Blizzardmanager.CreateNewObject<B>();
A a = Blizzardmanager.CreateNewObject<A>();

b.MyParentOfTypeA = a; //from this point a knows that it has a child instance, b


foreach(B b_child in a.Bees)
{
    //You will find the b object back in the list of a's children (a.Bees)
}


It’s worth mentioning that in standard c#, you cannot get a b in the a.Bees list unless you explicitly add the b object to that list:

a.Bees.Add(b);


A RelationDefinition contains the following information:
  • Types of associated objects
  • Roles of associated objects (child, parent, associate)
  • Relation sort (one to many, one to many composition and many to many)
  • Relation table
  • Relation field

A RelationInstance, besides the fact that it has a RelationDefinition with all its information inside it, contains the following information:
  • Relation Status
    • None (this is a relationship which is neither broken nor new)
    • Broken (this is a broken relationship)
    • New (this is a new relationship)


Update Process

When the Update method of Blizzard is called, Blizzard begins the update process from the perspective of relationships. It assumes that it can reach and handle all objects through their relationships. That’s why it first starts browsing through RelationInstances container dividing them in two groups: New and Broken relationships (RelationStatus None is not interesting because there is no change in the relationship against what at this moment exists in the database). For Broken relationships the Flow_RelationDeletion process will be started. And for New relationships the Flow_RelationPersistance.

But we are not done yet. Although the update process starts from the perspective of handling relationships and from that point handles the object attached to the relationship, what if an object does not have any relationship with another object (a standalone object) or what if a relationship has not been changed (so the RelationStatus is None) and does not go through those loops mentioned above. For these cases in the end of the update process, Blizzards goes through object containers and checks for changed, marked for deletion and new objects.

Last edited Sep 22, 2011 at 8:15 PM by hrSarmadi, version 23

Comments

No comments yet.