Object representations and transformations

An object has many representations. In a relational database, objects are represented as related tuples. In an object-oriented language, objects are instances of classes that have properties and behaviors. In an XML file, objects are elements conforming to a schema, belonging to other elements, and having both attributes and child elements.

Each representation of an object obeys certain rules. A relational database has foreign key constraints. An object-oriented language has a type system. XML must be well-formed.

Each representation of an object has certain limitations. In a relational database, all related objects must be co-located. In an object-oriented language, not all objects can be loaded into memory simultaneously. In XML, only one narrow branch of a hierarchy can be represented in a single document.

Each representation of an object has its own concept of identity. A relational database has keys. An object-oriented language has references. XML has paths.

When an object crosses the boundary between two representations, it must simultaneously conform to two sets of constraints. To load an object graph from a database into memory, we map ids to references, we map data types, and we store related objects in collections. To turn that object graph into an XML document, we traverse the collections hierarchically, convert non-hierarchical references into paths, and serialize it according to a documented schema.

I am building a framework for moving objects across boundaries while preserving their integrity. This system has its own concept of identity, its own set of rules, and its own limitations. Rather than trying to accommodate all of the other possible representations, I've started from scratch. In the coming posts, I'll define the system.

3 Responses to “Object representations and transformations”

  1. Mike Pone Says:

    Isn't there already an ORM (object relational mapping) tool for C#? I'm coming from the JAVA side where we use Hibernate to presist our objects to a database. It also looks like you need to represent the object as xml. You might be on your own for that one, but essentially, you're just serialing the object as xml and that should be a solved problem already with all the work done with SOAP. I'm just trying to save you an awful lot of work.

  2. Michael L Perry Says:

    Yes, there are tools to do the conversion for you. There's NHibernate, LLBL Gen, Entity Framework, and many other ORMs for C#. And for XML, .NET already has some good tools for both parsing and generating documents.

    Still, you have to turn the corner. The tools write a lot of the code for you, but you still end up with several representations of the same object. Instead of transforming an object, I'm creating a framework in which there is only one object. It doesn't matter if it is in the database, in memory, or on the wire. These objects always obey the same set of rules.

    I've already coded parts of the system both in Java and in C#. By the time I'm done, even the language won't matter.

  3. Ron Welch Says:

    I for one am looking forward to hearing (reading) your thoughts on this subject and hopefully seeing your code as well. The object relational impedance mismatch is a well known, and hard, problem, but it sounds like you may be approaching things from a different perspective...it should be interesting.

Leave a Reply

You must be logged in to post a comment.