Re: Mapping SQL Result Sets to Browsers

[john e <jacobus1968@xxxxxxxxxxx>]

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