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:
Asked by Apolon Ivankovic. Answered by the Wonk on January 8, 2003
A.
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.
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.
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.
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. : )
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.