Re: Mapping SQL Result Sets to Browsers -- WEB400

Joe wrote:

In a *proper* OO design, a single row from an RDBMS may actually require
instantiating objects of multiple classes. And, perhaps less
frequently, multiple rows from an RDBMS may result in a single object
(typically this happens with what we call "extension files" in the
enterprise world - files with the same key as a standard master file,
used to hold site-specific customizations). Most ORM tools don't even
begin to handle that level of complexity.

The impedance mismatch between relational databases and OO is a real problem, adding lots of (unnecessary) complexity. But this situation will continue for a long time because of the vested interest in relational databases and ORM tooling/consultancy.

I tend to see the directly instantiated objects as part of the database layer. So no complex ORM rules, but simply instantiating one record into one object. And use some custom code to instantiate the actual businessobject from these RDB objects.

As a side note, the "i" would be a superior platform to implement a real OO database to get rid of all these mapping non-sense. So you would have plain objects (in Java or maybe even in RPG) which would be simply marked as persistant. There would be no difference from the programmer's view between persistent and transient objects. Like the Gemstone database for example.

Date: Wed, 9 Jul 2008 09:33:54 -0500
From: joepluta@xxxxxxxxxxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers

john e wrote:

Off topic... but couldn't resist... :)

Joe said:

Different rules for different object types is important. The OO answer
is to have different classes for each, but all of a sudden you end up
with a complex and fragile object hierarchy. Not necessarily a bad
thing, just something that happens and is not always handled well by ORM
software.

A complex and fragile hierarchy is always a bad thing.

Introducing different account classes because of different calculations for "available balances" is a bad idea. Instead it's better to factor out these calculations into a different type of object, for example an "account-type" object which may delegate this calculation even further to a "balance" type.

In general, subclassing is not re-use and is often misused resulting in brittle code. A good OO design has a clean distinction between object types (interfaces) and their implementations (classes) and uses composition over subclassing (because the latter breaks the encapsulation principle because you deal with implementation issues directly).

A good OO design gives you software that is easy to adapt to changes and is extendible.

Not really off topic, John. In fact it does point out the problem with
using terms like "business object" too loosely. If you're talking about
true OO, you have to take into account the hierarchy issues. Also, too
often the term "business object" is used in conjunction with ORM
frameworks, which further confuse the issue because they rarely follow
practices like the ones you're suggesting, where different business
rules are encapsulated in different classes.

In a *proper* OO design, a single row from an RDBMS may actually require
instantiating objects of multiple classes. And, perhaps less
frequently, multiple rows from an RDBMS may result in a single object
(typically this happens with what we call "extension files" in the
enterprise world - files with the same key as a standard master file,
used to hold site-specific customizations). Most ORM tools don't even
begin to handle that level of complexity.

In any case, the whole discussion of "business objects" is too vague for
my taste. When you aren't specific about languages and implementations,
talking about relative performance and scalability is like trying to
decide whether Superman is tougher than Batman - fun perhaps, but
ultimately impractical in the real world.

Joe
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

_________________________________________________________________
Probeer Live Search: de zoekmachine van de makers van MSN!
http://www.live.com/?searchOnly=true