Partager via

ObjectSpaces Myths

  • Article

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
type.

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

  • Anonymous
    November 03, 2003
    The comment has been removed
  • Anonymous
    November 04, 2003
    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.
  • Anonymous
    November 05, 2003
    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?
  • Anonymous
    November 06, 2003
    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?
  • Anonymous
    November 09, 2003
    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.