When I first looked through the .NET framework, it was exciting to see the breadth of the framework and all the ďgoodiesĒ that were present. One area that I would have liked to have seen standardized are interfaces/classes for object persistence Ė as opposed to the table oriented nature of ADO.NET.

So, when starting on my first .NET project the approach that was taken was to use an OO database and build a simple OO persistence API on top of that. The intent is to be able to replace the database with a commercial RDBMS when and if needed. The theory is that this could be achieved using an object relational mapping tool (as more become available in the .NET world). This approach has gone well and I especially enjoy being able to think purely in an object perspective with respect to storage. Regardless, it hasnít all been smooth sailing. The areas that have slowed me down or are future problem areas with using an OO database approach include:

Sometimes I wonder if it would have been more time effective to have gone with the purely ADO.NET ďway of doing thingsĒ.

So (after the long winded intro), my ďask the wonkĒ questions are:

  1. In your opinion, what are the proís and conís of going with an Object Relational mapping tool as opposed to using a purely ADO.NET approach for database access?
  2. In what development scenarios would you recommend using an OO database instead of an RDBMS?
  3. What do you know about Microsoftís ObjectSpaces?
  4. In the long term (> 2 years), do you think the ObjectSpaces API will supplant the ADO.NET API with respect to importance for application code?
  5. Is it worthwhile considering the various .NET Object Relational mapping tools now given that Microsoft are going to release such a tool in the future? My main concern here is how dependant a set of source code becomes on the API inherent in using a specific object/relational mapping tool.

Asked by Apolon Ivankovic. Answered by the Wonk on January 8, 2003


Now that's a nice, juicy question, Apolon. Thanks!

You didn't ask about this, but you implied that .NET was missing a standardized set of "interfaces/classes for object persistence". In fact, .NET has not one but two serialization stacks, although both are client-managed, i.e. a client initiates the load and save instead of the objects themselves. This is as opposed to object-managed persistence, where the objects decide when to write themselves, like in an object-oriented database.

OO-Relational Tool Pros & Cons

I agree with your assessment of the cons of OO-relational mapping tools, but you missed what I consider the most important lack in OO-relational mapping tools, i.e. exposing the power of the underlying relational model, particularly the query language. While itís true that I can wrap tables, queries and stored procs in type-safe wrappers, the overhead of the wrappers because an administrative burden, particularly if every single query is wrapped. You could go the other way and always pull out entire hierarchies of objects, like you would in an OO database, writing standard OO code to pull out the data on the client-side youíd like to act on, but the overhead there can be tremendous, as youíll pulling in everything just to get at a subset of the data. One of the nice things about OO databases is their lazy serialization, i.e. no data is pulled Ďtil itís needed. No OO-relational mapping Iíve seen pulls off that trick.

The way OORM layers are generally implemented leads to another real downside of OORM layers: a much greater chance to write inefficient code, particularly as related to round-trips to the database. Itís common for OORM layers to need to retrieve multiple levels of hierarchy in multiple round-trips instead of in a single round-trip as would be preferable. When using ADO.NET directly, itís easier to see the multiple round-trips when compared to OORM layers which hide these details (by design).

As related to the maintenance chore of wrapping every single query in your system is the ongoing maintenance of the data layer as related to changes in the database, although this has to happen somewhere. If the OORM layer can be automatically generated, this chore can be lessened (although generally not eliminated).

On the other hand, there are pros for an OO-relational mapping layer as well:

Myself, I tend to use a hybrid between OORM and raw relational data, using some object layer for most things and direct access for ad hoc querying or filtering. The latter is particularly useful when I can get the database to do the work more easily than I can do it in .NET code, e.g. calculations, joins, etc.

When to Use OOD?

I think that the way that most OOD systems work moves for a convenient, efficient programming model and it would be even more so if mapped to .NET. However, I canít recommend OOD. Relational data is so firmly entrenched into the literature, the tools and the very psyche of most developers that Iíd have to have a damn good reason to switch to OOD and Iíve yet to see an application where Iíve had that.


I donít know much about ObjectSpaces beyond what you can get from a Google search (I use the Microsoft-specific Google search front end for such things: http://www.google.com/microsoft.html). I know the goal is to provide an OORM layer for .NET and that the real bits have changed dramatically from the alpha bits that they released some time ago.

ObjectSpaces vs. ADO.NET

Do I see ObjectSpaces replacing ADO.NET? No. ObjectSpaces will be built on top of ADO.NET and, like all layered architectures, youíll need to know whatís going on at the lower levels to take good advantage of the layer youíre using primarily.


Will ObjectSpaces become the primary API to relational data? That remains to be seen. When Microsoft gives something away and embeds it into the tools, it tends to have a good chance. However, there have been plenty of technologies that have received this treatment from Microsoft that have never caught on (ActiveDocuments being my favorite example).


ObjectSpaces has another strike against it in that OORM layers have been around for decades and theyíve never really taken hold. They tend to be too inflexible, too expensive and too darn slow to make them generally useful. Plus, the OORM problem is a hard one to solve in the general case, just as mapping between objects and XML is hard. Because itís a really hard problem, OORM layers tend to be inflexible, i.e. simplifying assumptions are made to ship and those assumptions donít hold for a large enough population. Still, if ObjectSpaces can solve the inflexibility and performance problems like they plan to solve the expense problem, I know Iíll be using it. : )

OORM Now or ObjectSpaces Later?

I donít ever recommend waiting on something from anyone when youíve got a problem to solve now. All software problems can be solved by waiting for someone else to solve them, but a lot of time and opportunity goes by while you wait. Pick a solution now that meets your needs and go serve your customers.


I have feedback on this Ask The Wonk answer