ObjectSpaces

Comments

# Paul Bartlett said on January 21, 2004 07:34 AM:

Martin Fowler compares the full blown Domain Model pattern with simpler ones, such as Table Gateway in his book Patterns of Enterprise Application Architecture. I guess as ADO.NET provides is pretty much a Table Gateway with no need for user code with strongly-typed DataSets, you might need a more complex solution before reaching "break-even" with an ORM. You might also want to check out NEO (now at http://neo.codehaus.org/) as an alternative ORM.

# Frans Bouma said on January 21, 2004 07:45 AM:

"... Your application passes objects and gets objects in and out of the data source. Any serialization/deserialization process is taken care of and application developers don't need to know about the data model and SQL details."
This is a myth, Dino :)
serialization/deserialization is not done. This is because you are using your own code for the classes. Therefore, if you want them to be serializable, you have to add the logic yourself. (i.e.: if you add an eventhandler, you have to implement ISerializable and if you add a member of an interface type you run into trouble with the XmlSerializer which is bad for webservices.).

Developers DO have to know about the relational model. Because the developers develop the classes themselves, they have to know an order relates to customer in a m:1 way so that the 'Order' class has to be able to hold a reference to the Customer class and the Customer class has to hold a reference of a collection meant for Order classes. Furthermore, if you want to filter on objects, it is very useful that you understand which objects are mapped to which tables and how these are related so you can formulate a good filter (query) which will actually be what you want in SQL. This is impossible without knowing the relationships in the model.

"...What's the real cost of this code?
For Each c As Customer in reader

' ...

Next"
The real costs are not in that kind of code. The real costs are in the tracking code of objects. Because you are using your own classes in Objectspaces, it has to do either one of the following things to keep track of changes of properties:
1) keep a copy of the original object so it can check which fields are changed (slow)
2) alter the byte code of the object at runtime so it can insert event handler calls into the memberset code in the properties (dirty)
3) do not check for changes but assume that ALL fields are changed

1) is slow because it has to verify each property when you want to save an entity/update an entity. This can be cumbersome if the entity contains for example an image or a big blob of text. In the Java world this is seen as the wrong way of doing things.
2) is faster but because of the runtime bytecode changes, it is IMHO a dirty way of doing things which can lead to possible problems with own code.
3) is also slow, because you execute a lot of extra SQL in a lot of situations (imagine you update a single field in a 20 field table)

When I checked the SQL generated from Objectspaces for an update query I saw that they opted for 3) as it seems.

Another solution would be
4) use a base class for the entity classes which takes care of the plumbing code like fields and other code for housekeeping like tracking changes.

Personally, but I'm biased ;), I never would have opted for the non-intrusive way of doing O/R mapping (they could have opted for an interface to be implemented) because it will bring a lot of problems for the user of such a tool: how to support complex databinding for the customer.Orders collection? -> you don't want to let the user edit PK fields, and other fields which are read-only. This requires ITypedList and property descriptors. Not a nice thing to do :) (and I haven't talked about IBindingList :))

# Kathleen Dollard said on January 21, 2004 09:41 AM:

How complex is my ORM?

Mine is as simple as I can get away with, and unfortunately, that's not very simple in terms of the actual ORM process itself.

My perspective is code generation with the base model of abstracting the business information (business metadata) away from the technology (templates and components).

From the perspective, I anticipate the business model having a very long lifetime - potentially more than a decade. The business metadata is an abstract view of the business and its data. To maintain the viability of this across the massive technology changes a decade can bring requires abstraction. Pragmatically this is an abstraction layer between the database and the business objects. That’s the job of ORM.

The ORM is a pluggable layer that can start out simply allowing mapping. With current technology, ORM can be partially or wholly implemented in stored procedures - which can be generated from the ORM model, along with the corresponding extendible plumbing business objects. I think people that don’t perceive themselves as using ORM are actually using this sort of simplified version in their stored procedures and logic to load their business objects. You at least control the columns and children returned.

The goal for my ORM is to be only as complex as it needs to be to raise this mapping from being encoded as technology to being a true abstraction layer. This explicit abstraction offers the possibility of a much more complex mapping in the future - such as across diverse storage technologies.

We need this ability to map during development to accommodate future change, and we need it to have no impact, or a positive impact on other quality issues such as runtime performance. That brings us back to ObjectSpaces. When I saw ObjectSpaces at PDC, I was under the impression that it was fairly slow, especially compared with managing your own business objects.

# Rick Strahl said on January 21, 2004 07:24 PM:

It seems pretty frustrating to see Microsoft fail at clearly defining ObjectSpaces. Even in the Whidbey builds there's no clear vision on how this is supposed to work - the spec seems completely open and incomplete at this time.

ORM is definitely something useful if done right, but like you I worry a lot about the overhead involved. It's bad enough to have business objects in an application that acts as a fairly thin veneer around your DataAccess layer - all of this adds overhead and ObjectSpaces and the like will then sit on top of this. In this respect ORM becomes a sort of framework of itself and I'm not sure that this is a good thing coming from Microsoft or other big vendor, because those solutions tend to be a bag full of things that address a very low common denominator.

The big problem is that ObjectSpaces and other ORM implementations implement their own middle tier. So you're locked into a specific way of doing your data access which in many cases is sub-optimal. It's not always a bad thing, especially if you're dealing with customers who have no interested in imlementing a custom data access layer.

This may or may not be a problem depending on the application, but if you go with a full ORM approach it's much harder to not use the ORM logic than it is with more traditional business object approach where you can always implement custom methods to do what you need anyway you like. In ORM for consistencies sake you will always want to go with the ORM metaphors.

Ultimately I find it interesting to contemplate what the real value of a particular abstraction is. ORM is a more natural abstraction that a typical business object, but it doesn't really provide much additional functionality that you can't already provide with a typical business layer which IMHO is more flexible simply because it is a bit more low level. Sure it's nice to have an ObjectReader, but how hard is it really to read a row from a result set and have your business layer parse that into a business object data object?

BTW, where did you find offical information on ObjectSpaces and its non-release status for Whidbey? Is this official or an assumption?

# David Hunter said on January 26, 2004 11:00 AM:

FWIW in http://www.microsoft.com/belux/nl/msdn/community/columns/jtielens/objectspaces.mspx the claim is made that ObjectSpaces are part of Whidbey.

Leave a Comment

Title (required) 

Name (required) 

Your URL (optional)

Comments (required) 

Remember Me?