XmlObject - Adaptive Object Model

Better Designs Faster

Developing Applications

Implementing an Adaptive Object Model is for the most part like implementing any other object model.  You are still best served by having well established processes and by not deviating from them when the going gets tough.  You can treat requirements differently than when faced with implementing a static object model.  With static models we know that we are going to be building a model with less abstraction than with an Adaptive Object Model.  This means tighter coupling and higher costs should things need to change.  Avoiding change is easiest if the requirements are both complete and relatively stable.  With the XmlObject Framework we know that we have a built in layer of abstraction at the XmlElement class.  I am a tiny bit less concerned about risk if the development moves forward with incomplete requirements.  Note the emphasis on tiny.  A layer of abstraction is not an excuse to abandon years of best practices. 

If you are looking for a place to start when implementing your own Adaptive Object Model, I suggest the following steps. 

Single tier or multi-tier development

Decide how you are going to partition the application’s various responsibilities.

Develop the data model

It has been suggested that a good way to measure an applications quality is to gauge the quality of its underlying data store.   This can be as simple as creating sample data in a XML document, or as complex as creating a full Entity Relationship Diagram.  Here is a short page that covers this important technique.  I cannot over recommend following its example.

Object model navigation

Closely related to the design of the data model is how one navigates the data model.  The XML DOM has navigation built in in the references it maintains and of course one can always use XPath.  XPath is very powerful, but an over dependence on XPath for object model navigation can lead to a fragile design.  Just being aware of the issue is often enough to keep it from being a problem.

Decide what assemblies are to contain what business logic

Say that you are creating a custom business application that manages standard customer information, things like name, address, etc.  Likely you would want to separate business logic for managing customer information from the business logic of your main application.  The XmlObject will support this automatically if the design has different XML prefixes and namespaces for business logic that is functionally distinct.

Resolver design and implementation

Once you have logically partitioned your business logic you can design your XmlObject Resolvers.

User Interface considerations

It is unlikely that you will organize your user interface the same way you organize your data model.  It is very easy to create an XSLT transform to resolve any impendence mismatches between presentations layers and business logic layers.  Herein lies the true power of the XmlObject Framework over other ways of implementing an Adaptive Object Model.

Alternate data representations

In a very large development it is likely that there will need to be some measure of independence between development groups.  By using the XmlObject Framework you afford yourself an extra degree of freedom.  With a minimal amount of coordination, separate groups can proceed with their developments for the most part independently, trusting that any mismatches between schemas can be addressed with an XSLT transform.  This of course comes with a cost, but that cost could be orders of magnitude less than the cost of synchronizing the development efforts of two or more large groups.