Re: Mapping SQL Result Sets to Browsers

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.


----------------------------------------

Date: Tue, 8 Jul 2008 10:14:29 -0500
From: joepluta@xxxxxxxxxxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers

Nathan Andelin wrote:

I guess the point, is that you may need to plan for a lot of flexibility, and change as business rules change.

Agreed. I'm sort of avoiding this very high-level discussion of
architectures because I've already been there and done that and I have
my own opinions, and rather than bollox up the list with my
pontification I'm enjoying the interplay (hence the "from the bleachers"
comment). But hopefully I can help people avoid certain pitfalls I've
encountered.

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.

An even trickier issue is when you get different values for different
users. One specific example is social security numbers. In at least
one system I've seen, a user with high authority gets to see the real
SSN, while someone with a lower authority sees a special garbled value.
Technically I suppose this is a presentation layer issue and the object
could contain both values, but then you have security concerns. In any
event, it's something that needs to be considered.

In any case, you're right - once you begin injecting business rules into
the ORM layer, a large number of issues come into play. Everything from
authorization to latency needs to be addressed.

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.

_________________________________________________________________
Jouw nieuws en entertainment, vind je op MSN.nl!
http://nl.msn.com/