Wednesday, September 22, 2010

Model Distribution with IO Engine

ModelDifference module is one of the powerfull modules of eXpand . It really helps in managing your application models.

Scenario
Your application has been already distributed to your client and you no longer have access to the production database. Your client admin is responsible for that. But since development never stops as you know, you client asked for some model modification and some new application models (lets say 10) have been developed by your team and you want to sent them to the admin to update the application.

eXpand IO module is the right one for the job

Step1—Create a serialization graph to configure which objects/values you are going to export

In order to create a serialization graph for an object type you have 1st to create a Serialization Configuration Group, that is just a container to help you organize your graphs

image

Given that you want to export Models you have to create a graph for the ModelDifferenceObject persistent class

image

When you set the Type To Serialize editor value (1) IO module will automatically fill the values of the nested listview (2) by populating the properties of the Application Difference object, and also will create graphs for objects that are connected with Application Difference object (3)

Step2--Clean automatically created graph

You may wondering how the graphs in the number (3) of the above image are created. If you see the domain model of the ModelDifferenceObject you will see the relation between all these objects.

image

So what IO module does goes through all those relations and create graphs for each one of them, since due to object polymorphism it is impossible to know the type of the object from the start. But you do!! You know that you are interested to export only ModelDifferenceObjects and not RoleModelDifferenceObject or UserModelDifferenceObject so you could delete all other graphs as showh bellow

image

Step3—Choose Serialization Strategy

This screenshot are taken from eXpand feature center and as you see there are some properties that we may not want to export such as City,UserFilter,Skin. We can exclude them from the export process by choosing a DoNotSerialize strategy

image

Now for the  most interesting and hard step. As you see from the domain model above ModelDifferenceObject has M-1 relation with the PersistentApplication object, also by the name of PersistentApplication one can understand that the already distributed application already have that object and we not want to export its properties but only its key, so choosing a SerializeAsValue strategy will solve that one also

image

But we have not finish yet. If you think again what we did is export only the key of the PersistentApplication, but the key type is GUID meaning that the distributed application with the one from the which we are going to export will have different keys. To solve this one we have to go to the PersistentApplication Graph and change the key from Oid to UniqueName, thus IO engine will not get confused and will used the appropriate object

image

image

Step4 –Select and export models

Just go to a list view that has the objets you are interested to export and use the IO/Export action

Step 5—Import the exported objects

This process is very easy and only requires to use the IO/Import action and choose the xml file .

Subscribe to XAF feed
Subscribe to community feed

DiggIt!
blog comments powered by Disqus