Should the struggle for OR mapping continue?

Paul Gielens is struggeling with OR mapping:

I DO NOT want to use setters (at least not for the OID, not at all actually because the object is a read only except for the lazy loaded associations)…

I've tried to make a similar framework but I'm leaning more and more towards discarding OR-mapping as an alternative. Clemens Vasters gave me the final push in a breaktime discussion a month ago during the Scalable Apps tours visit in norway. Successful OR mapping might be flawed by definition because you'll never fully be able to ensure that you are operating on the same object (unless you use prevalence).

The OID is also a contradicion in terms, because the actual reference-pointer to the object is the only true OID. The java community is working with CMP/CMR and different loading techniques but concurrency, scalability and performance are issues in the way. Bean Managed Persistence is still their perferred way.

It's possible to create a framework based on business entity objects and something resembeling the J2EE Pattern Data Access Object / Transfer Object / Value Object. Concurrency and persistence can be built into this, and you can make the DAO's XML configurable. Except for the OID the use of setters are actually no real problem. You need to handle concurrency anyways. The J2EE pattern Value Object have a strategy called "Updateable VO"that suggests this behaviour.

Microsofts ObjectSpaces initiative is kinda like this, but it seems to go nowhere (complete MS silence). They have implemented a version of lazy loading, but not with "real" objects. It's got no support for inheritance or polymorphic queries. Transparent OIDs are not supported and you'll need to handle it on your own (in stored procedures or code). Also you still have to create your own database objects which requires a lot of thought and consideration related to performance and maintanability.

I've tried out both (custom framework/objectspaces) and found that it requires too much coding (framework) and/or a application architecture I'm not comfortable with (objectspaces).

My feeling is that OR mapping will never be successful before we developers can completely forget about the database. At the moment that's no option. My approach is to go more Service Oriented. I make services that consume messages, often business entities like typed datasets or typed datarows. I don't view these as pure oo-style objects. I regard the XSD definition of the generated typed dataset classes as the fundamental typedefinition. Handling of associations and aggregation must be adressed on a case-to-case basis, which also enables implementation of caching-, and concurrencystrategies, and also datasourcehandling in the datalayer.

Maybe we should forfit the struggle to create the perfect OR mapping and focus more on the SOA approach?

4 Comments

  • Don't confuse the PDC preview with the final version.

  • I haven't seen the final (is there a final version?), but I've seen later versions than the PDC. Do you have more information?

  • DataSpaces is the next gen service layer on top of ADO.NET (as Jesse mentioned before). There should be more info on the Tech-Ed DVD's.

  • You have to wait till PDC, but suffice to say that there will be significantly more functionality than was in the preview. Remember, what you have seen wasn't even an alpha, it was just a technology preview. A lot of stuff has changed since then (like you can use ANY object you want, instead of having to define all those abstract members).

Comments have been disabled for this content.