ObjectSpaces Myths

From the Post-PDC 2003, feedback there seems to be a number of fallacies circulating
about ObjectSpaces.  I have attempted
to answer of few of those below:

ObjectSpaces is a thin layer over ADO.net

ObjectSpaces utilizes the SqlClient support
of ADO.net to query and persist to Sql Server, it however does not use the ADO.net
Dataset in any way.


ObjectSpaces does not provide a ObjectServer
or a caching mechanism.

ObjectSpaces is designed to be a low level
component like the ADO.net stack.  It
therefore does not implement any sort of server architecture for three tier and/ or
distributed applications.  However, the
components have been designed with these sort of scenarios in mind so just like Datasets,
users who want to build this infrastructure with .net and ObjectSpaces will find the
task rather straight forward.


Span can only be specified at design time.

Actually it can be specified at both design
time and runtime.


MBF will not use ObjectSpaces

The opposite is true, MBF will be built upon
ObjectSpaces and will fully utilize ObjectSpaces as its Entity persistence layer.


ObjectSpaces will not support inheritance

Actually all three of common O-R inheritance
scenarios are supported.  1)  Single
table with type discriminator 2) One table per type And 3) One table per concrete


ObjectSpaces and the new managed SqlXml are
two entirely different products.

Actually, the products share common mapping/
query/ persistence engines and the teams work very closely on the sharing ideas and
features.  In fact several of us of worked
on both technologies.

Comments (5)

  1. BobSmith says:

    Did you mean to say…

    "it however does NOT use the ADO.net Dataset in any way" ? Want to make sure I understand you.

    Also, do you have a link to an ObjectSpaces reference? I was so caught up in Avalon and Indigo info from PDC, that ObjectSpaces seems to have fallen through the cracks.

  2. AndrewConrad says:

    Yah… thanks for catching that mistake. I have updated the entry. I guess I know something about ObjectSpaces but not much about grammer.

    We are working on getting some ObjectSpaces’ reference material out on the web. Unfortunately, there isn’t much at this point though. Your best bet is to look at the documentation included with the Whidbey .net SDK.

  3. Kenneth Brubaker says:

    However it’s NOT a myth that ObjectSpaces is spec’ed to be 40% slower than DataSets, correct? I don’t understand why that must be. If (1) you don’t have to build data definitions and table relationships as you do in DataSets and (2) you can compile to CIL like XmlSerialization does, why can’t you make it faster than DataSets?

  4. The first two ‘myths’ are mine and your answers confirm what I tried to say (perhaps I was not clear), and I’m glad they do, as I really think it’s good for ObjectSpaces to be that way.

    I think you need to explain the 40% slower thing. Luca said that, but it was really not clear what was we comparing to. To use stored procedures? To use plain ADO DataReaders? To load a DataSet from a DataReader vs loading an ObjectSet?

  5. Ray Jezek says:

    I didnt get the impression that he (Luca) was talking about datasets.. i thought he was talking about DataReader.. and he seemed hesitant to say much about that because it’s not a finished product yet either so you dont know what the performance will be in the end. But its hard for me to imagine it will be slower than a dataset? Unless the mapping file translation and sql generation takes a really long time.