ObjectSpaces: What’s the big idea?

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 ADO, connections, commands and recordsets.  I had to pull out my own book on the subject just to remember what to do.  Luckily, I also spent the last nine years working on this technology, so when it came to crafting up some SQL queries it was not too tough, except they weren't really SQL queries, they were Jet SQL queries meant for an Access database.  Sure, I should have been using a version of SQL Server, but it wasn't my app, I was only volunteering my time to put in new features.  So I struggled to get the queries just right, trying to figure out what to do using the Access product documentation, which is great if you want to learn how to use a menu or item in the user-interface, but when it comes to documenting the query language it is none too helpful.  It was at this time that I wished the application were more of an honest-to-goodness professional style app with a good data access abstraction layer, then maybe I wouldn't find myself scratching my head at 3 am wondering how to translate a subquery.


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.




Comments (12)

  1. Dennis says:

    Sounds cool. Finally an object-database team that "gets it."

    Where I work, we’re constantly doing adhoc queries…is that still doable, or do you pretty much have to write code and compile something?

    And…the magic of sql is that the output of one query can be fed into another query…can objectspaces do that?

  2. Matt says:

    You can still do ad hoc queries. What you might have seen so far has limitations, but we keep refining it. The newer version of the OPath query language is fully composable, just like SQL in that respect.

  3. Paul Wilson says:

    Does this mean that ObjectSpaces is going to support Access and/or other databases in the first release afterall?

  4. Jason Mauss says:

    Yeah, I have the same question as Paul. I hope ObjectSpaces supports other databases besides SQL Server.

  5. Matt says:

    I have no control over what actually gets shipped, and am not privy to the current plan of record. Architectually, ObjectSpaces can work with different back-end providers. If only SQL support ships right out of the gate, eventually something will have to give. Microsoft does listen to its customers.

  6. Ferris Beuller says:

    Or something wont have to give, its called money and we are holding it.

  7. I wonder how well does ObjectSpaces scale. It’s a marvelous idea for small to medium projects. But I’m still scared about using such a product in large scale DB-savvy projects. Stored procs + ADO/ADO.NET scale, and they are proven. Have you done heavy load stress tests on it?

    What’s your advice?

  8. Matt says:

    ObjectSpaces is basically a mapping veneer over ADO.Net, so technically it scales just as well. It can depend on how much ‘mapping’ you do, and of course how well you layout your database in the first place, but that’s always the case. The cost of objectspaces at runtime is really just the query translation before it hits the database and object construction cost after.

  9. How about some source code examples? I haven’t seen any anywhere, only conceptual discussions.

Skip to main content