Attention: We are retiring the ASP.NET Community Blogs. Learn more >

ObjectSpaces

Some information about ObjectSpaces that was given in Luca Bolognese's presentation:

- It is designed to be a thin layer on top of ADO.NET. It's just as ADO.NET but with objects. There isn't an object server and they don't provide caching, so it's not a Entity Beans clone.

- They are targeting a 30/40% performance decrease compared to the DataSet/ADO.NET approach. They are currently 2 times slower.

- One of the usual issues with O/R mappers is that they have to decide how to load an object graph. Using the example from their demo, if you have:

Continent
   string Name
   ArrayList Countries

Country
   string name
   Continent continent
 
if you retrieve one Continent, you could want to load all its countries or not. In ObjectSpaces you can specify a 'span' when you query for Continent that says that you want to retrieve the Country, or leave the span empty to specify that you just want the Continent but no the Country.

The other way to deal with this is to use 'Lady Loading' (which Luca said they'll call 'Delayed Load' because marketing did not like 'Lazy' ;), which means that countries are loaded the first time you access the Continent.Countries property. To do that you need to use a special class for the collection. You cannot use ArrayList, as they need to have a hook to execute the data loading code when you access the property. The same happens if you want to lazy load a field (i.e., the 'continent' field in 'Country')

- They are using reflection to load the fields from the database. It seems in Whidbey there is a feature called 'Lightweight Reflection' that is really fast.

- The first version will support SQL Server 7 -> Yukon. They will provide a way to add support for other Managed Providers in the future.

UPDATE:

Andrew Conrad made some clarifications on the performance issue.

 

3 Comments

  • Great. Means they are second grade :-) The performance impact is terrible - our ENtityBroker is FASTER than using DataSets.



    Also, the Spans - this is VERY bad. Why? It is decided at COMPILE TIME of the OBJECTS.



    BUt preloaing is an optimization of the LOADER.



    Example:

    Invoice-InvoiceItem.



    I load the invoice for editing: i need the invoice items.

    I load the invoices for showing a list of them - I dont give a dime about the items.



    Now, with ObjectSpaces it is either Span or Lazy Loading.



    With a good mapper (and thank heaven the EntityBroker is just adding this feature), you can decide this the moment you ask for the objects.



    The missing ObjectServer makes it even worse.



    not a bad intro, but definitly not a good approach for high performance.

  • 2 times slower? Whoa :)

    The absence of a cache is not a big deal, but the absence of an object server is, because they do not have generated code which contains the relations and other constructs embedded.



    Indeed, compile time lazy loading is a very weird design decision, because it is so simple to implement it so it can be decided at runtime. Also, they totally forget about bulk operations on entities: when you want to update a group of employee entities, you have to load them first into memory, alter the properties and then save them back, while it would take a single update statement to update htem all in the database. A waste of resources.



    Lists of entity fields for read-only viewing of data (like the order row and the customer name in one list) are not available, which will leave the developer to use techniques outside the object space to perform it: with a view that is read into a dataset by hand.

  • Ouch. Target of 30-40% slower. I guess I should keep looking at Thomas and Frans' alternatives (and others) and go forward getting my team up to speed now.

Comments have been disabled for this content.