Should your data become objects or your objects become data? That’s the debate. If you build apps focused around objects and just want those suckers persisted then you want your objects to become data. If you’ve got a database and you are building apps around that data using an object-oriented language you probably want your data to become objects. Which is more prevalent, I don’t know, probably the latter.
What I am certain of, however, is that many people out there are struggling with data some way or another. You’ve got your ADO.Net, or just plain ADO, or maybe you’re an Einstein and do it all against OLEDB or ODBC or some other API du jour, and if you were still writing quick and dirty apps these API’s would suffice. I know. I’ve done it too.
I’ve recently been working in my ‘spare’ time on a web app that’s gotten me sucked back into the old-school ASP programming. I found myself writing code against
Sure, you’ve all been there at some point in the past. Most you have moved on to better designs and practices. That’s why you build abstraction layers. I know this is true, because as customers you tell us that you do. I’ve visited customer sites. I’ve seen some of the apps. They are marvelous and huge, testimonies to man’s ingenuity, and they can’t get that way without abstraction. But a data access layer can be difficult to build, difficult to get right. It can consume a project team.
That’s why we’ve built ObjectSpaces, so you don’t have to. ObjectSpaces is the ideal data abstraction layer. It lets you define your application in terms of your objects, and it gives a declarative way to describe how your objects correspond to your storage system. You do this once and you never have to look back. Okay you might have to look back and tweak it, but you don’t have to tweak your code, just the mapping.
ObjectSpaces is the ultimate abstraction layer because it does not lock you into a fixed set of library methods like GetMyObjectX and GetMyObjectY. You can still write queries. You just don’t have to query the storage model in the database. Your queries refer to the objects you use in your code. Best of all, there’s just one query language that you use, regardless of where the objects are stored. If the objects are in SQL server, then OPath translates to SQL server’s dialect. If the objects are in Jet SQL then that’s what is used to communicate to your data.
So are your objects data, or are your data objects? It does not matter really which way you come at the problem. ObjectSpaces works both ways by taking the middle of the road approach. You don’t just get a turn-key system that takes your object structures and dumps them into an uncertain stasis, inaccessible to other apps in your business. That’s never worked too well and is one of the primary reasons object databases failed. And you don’t just get a system that gives you straight objects in place of database tables. You get to design your own objects, and you get to customize how they are stored. It might sound like a little more work up front, but it is well worth it. A working abstraction layer with endless tweaking ability, that’s the big idea.