Mixing P/R philosophy with OO (within J2EE).

Hello,

Assuming:
1. we are very much within the custom-business software niche; and
2. we are developing a J2EE-based application...


1. What strategies would OO-critics (such as TopMind) and P/R fans (if
any here other than TopMind) advise to avoid needless translations
between OO and Relational paradigms? Ref: http://www.geocities.com/tablizer/core1.htm

2. TopMind appears to make some very interesting points on OO and P/R
on the above site. However, how many of these ideas can actually be
realized today, say, within the J2EE world... where if you do
something even slight 'out of the ordinary' (like deciding to not
using Hibernate/Kodo in favor of embedding direct JDBC calls in your
business tier), you tend to not reap the full benefits that might have
otherwise come for 'free', today or in future, by sticking to normal
use of the platform. That is, from what I understand, once you are
in J2EE (or .NET) world, your best bet (as one of my friends suggests)
is to stick to everything plain and normal and common-sense, and to
not try any new architectural/design stunts unless they stand
sufficiently proven. (An example of the last point would be Stored
Procedures: a 'normal' J2EE developer would want to code the SPs
within the business tier (in Java) instead of in the RDBMS tier in
vendor-specific SQL... with the rationale being... the database can be
easily switched from let's say mySQL to Oracle to XYZ with zero or
minimal work overnight!)

I apologize for the J2EE-specific nature of my question... but these
days most folks are using only either J2EE or .NET for developing
enterprise class applications! And, on J2EE and .NET forums, no one
would have a clue about TopMind and his P/R insights. Hence, any
practical advice on the APIs, layers, etc that could be conveniently /
elegantly skipped (and, similarly P/R-centric software, APIs, etc that
could be used) to speed up enterprise class application design and
development would greatly put things in perspective for me.

Thanks.

Harry wrote:
> Hello,
>
> Assuming:
> 1. we are very much within the custom-business software niche; and
> 2. we are developing a J2EE-based application...
>
>
> 1. What strategies would OO-critics (such as TopMind) and P/R fans (if
> any here other than TopMind) advise to avoid needless translations
> between OO and Relational paradigms? Ref: http://www.geocities.com/tablizer/core1.htm
>
> 2. TopMind appears to make some very interesting points on OO and P/R
> on the above site. However, how many of these ideas can actually be
> realized today, say, within the J2EE world... where if you do
> something even slight 'out of the ordinary' (like deciding to not
> using Hibernate/Kodo in favor of embedding direct JDBC calls in your
> business tier), you tend to not reap the full benefits that might have
> otherwise come for 'free', today or in future, by sticking to normal
> use of the platform. That is, from what I understand, once you are
> in J2EE (or .NET) world, your best bet (as one of my friends suggests)
> is to stick to everything plain and normal and common-sense, and to
> not try any new architectural/design stunts unless they stand
> sufficiently proven. (An example of the last point would be Stored
> Procedures: a 'normal' J2EE developer would want to code the SPs
> within the business tier (in Java) instead of in the RDBMS tier in
> vendor-specific SQL... with the rationale being... the database can be
> easily switched from let's say mySQL to Oracle to XYZ with zero or
> minimal work overnight!)
>
You're tongue-in-cheek suggests you don't buy that approach. I agree.

I've written a couple essays on the subject of another way for OO and
RDB to work together, based off, unfortunately, a concept of
transactions. Unfortunate because the word transaction carries a lot of
luggage with it that has little to do with what's really happening under
the covers, and that's messages to the DB in the form of OO programs
affecting state changes through DB stored procedures.

Regardless, I'm developing a lecture for an upcoming Smalltalk
conference <http://www.it360.ca/smalltalk.cfm> based on those essays and
discussions in this newsgroup.

<http://blogs.in-streamco.com/anything.php?title=transaction_oriented_architectu re_aka_th>
<http://blogs.in-streamco.com/anything.php?title=the_rdb_is_the_biggest_object_i n_my_syst>
<http://blogs.in-streamco.com/anything.php?title=my_schema_is_an_class>

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

Harry wrote:
> Hello,
>
> Assuming:
> 1. we are very much within the custom-business software niche; and
> 2. we are developing a J2EE-based application...
>
>
> 1. What strategies would OO-critics (such as TopMind) and P/R fans (if
> any here other than TopMind) advise to avoid needless translations
> between OO and Relational paradigms? Ref: http://www.geocities.com/tablizer/core1.htm
>
> 2. TopMind appears to make some very interesting points on OO and P/R
> on the above site. However, how many of these ideas can actually be
> realized today, say, within the J2EE world... where if you do
> something even slight 'out of the ordinary' (like deciding to not
> using Hibernate/Kodo in favor of embedding direct JDBC calls in your
> business tier), you tend to not reap the full benefits that might have
> otherwise come for 'free', today or in future, by sticking to normal
> use of the platform.

Before we get into the politics of Java, there is something ironic
about O/R wrappers like Hibernate: they are almost more complex than
the RDBMS itself. Thus, one is wrapping the DB with something that is
practically a DB engine *itself*. Is being married to Hibernate less
of a sofware engineering change-flexibility "sin" than being married
to Oracle or PostGreSQL? I never figured out the "logic" behind such.
It appears to be hypocritical to me. I compare it to hiding behind
Dracula to avoid being attacked by Frankenstein. Databases tend to
outlast languages, or at least are switched at roughly the same
frequency as languages. Thus, vendor-swap math doesn't seem to favor
it.

> That is, from what I understand, once you are
> in J2EE (or .NET) world, your best bet (as one of my friends suggests)
> is to stick to everything plain and normal and common-sense, and to
> not try any new architectural/design stunts unless they stand
> sufficiently proven. (An example of the last point would be Stored
> Procedures: a 'normal' J2EE developer would want to code the SPs
> within the business tier (in Java) instead of in the RDBMS tier in
> vendor-specific SQL... with the rationale being... the database can be
> easily switched from let's say mySQL to Oracle to XYZ with zero or
> minimal work overnight!)

If you mean "go against the flow", there is indeed career problems
with that. You seem to be asking a social/political question rather
than a technology one. Java fans will tend to think and act a certain
way with their tools and expect things a certain way. If you go
against "Java culture", you indeed may put yourself in hot water. It
is probably easier to leave the Java culture than to change it. I've
busted my balls trying to run from the OO hype, and it has indeed hurt
my career. Attacking Sacred Cows risks getting yourself caught in a
hamberger grinder. I advise others to just go with the flow if you
like money. You may have to choose between money and truth.

However, when some new fad comes along and OOP/Java looks like COBOL 2
to everybody, you may be in a better position. I suspect the pendulum
will swing back to data-centric techniques (like it was in the
mid-80's) away from OO's code-centric techniques.

>
> I apologize for the J2EE-specific nature of my question... but these
> days most folks are using only either J2EE or .NET for developing
> enterprise class applications! And, on J2EE and .NET forums, no one
> would have a clue about TopMind and his P/R insights.

My detractors here want to keep it that way :-)

> Hence, any
> practical advice on the APIs, layers, etc that could be conveniently /
> elegantly skipped (and, similarly P/R-centric software, APIs, etc that
> could be used) to speed up enterprise class application design and
> development would greatly put things in perspective for me.
>
> Thanks.

Good luck in your choices.


-T-
oop.ismad.com

topmind wrote:
> Before we get into the politics of Java, there is something ironic
> about O/R wrappers like Hibernate: they are almost more complex than
> the RDBMS itself. Thus, one is wrapping the DB with something that is
> practically a DB engine *itself*. Is being married to Hibernate less
> of a sofware engineering change-flexibility "sin" than being married
> to Oracle or PostGreSQL? I never figured out the "logic" behind such.
> It appears to be hypocritical to me. I compare it to hiding behind
> Dracula to avoid being attacked by Frankenstein. Databases tend to
> outlast languages, or at least are switched at roughly the same
> frequency as languages. Thus, vendor-swap math doesn't seem to favor
> it.

It does if you are in the product business as opposed to
the project business.

Because then the resistance to change database actually
favors tools that encapsulate the database specifics.

Customer X may only buy your product if it runs on top
of database A. They do not care what persistence framework
you use to be able to support database A, B, C and D without
changing the application code.

In cases like that a persistence framework is a real
benefit.

Arne

Arne Vajhøj wrote:
> topmind wrote:
>> Before we get into the politics of Java, there is something ironic
>> about O/R wrappers like Hibernate: they are almost more complex than
>> the RDBMS itself. Thus, one is wrapping the DB with something that is
>> practically a DB engine *itself*. Is being married to Hibernate less
>> of a sofware engineering change-flexibility "sin" than being married
>> to Oracle or PostGreSQL? I never figured out the "logic" behind such.
>> It appears to be hypocritical to me. I compare it to hiding behind
>> Dracula to avoid being attacked by Frankenstein. Databases tend to
>> outlast languages, or at least are switched at roughly the same
>> frequency as languages. Thus, vendor-swap math doesn't seem to favor
>> it.
>
> It does if you are in the product business as opposed to
> the project business.
How many databases are you planning to support? Have you considered
creating some vendor-specific linkages to take advantage of features in
each?

Can your product be shipped with a DB engine? Does your product need to
integrate with other of a customer's data?

What kind of throughput do you need? Are concessions made in either the
DB model or the OO model so you can use OR wrappers? If your OO product
didn't exist would the DB model be identical?

Is vendor independence a feature of your current product or a desired
feature of your next one?

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

On Apr 3, 6:52 pm, Thomas Gagne <tga...{}wide-open-west.com> wrote:

> You're tongue-in-cheek suggests you don't buy that approach. I agree.

I do buy and, in fact, like most of his arguments on OO hype, noun-
oriented class design issues, etc. However, in absence of real tools,
API, (language support?) that encourage P/R style, you can't really do
much, can you? Unless there's an industry-wide initiative to revive P/
R mode of thinking, feeling, and acting a handful or two of ordinary
developers (like myself) can't really go upstream... :-)

I don't have language designing / compiler writing skills myself, so
can't really think in-depth / critically of all issues that would /
could later surface in TOP for large scale, real-world projects.
However, language designers (of major languages such as C++, Java,
Perl, Ruby...) would already have these skills, and I hope they have
considered TOP related arguments.

I think it was ANSI C++ that made popular the generic programming
style... which is heavily template-based, in which collections (data
structures) and algorithms are kept separate (though still as
objects)... which, imho, was a radical break from the usual OOD
thinking prevalent in the mid-90s (which, if I'm correct, was always
to club functions together with data without exception) . So, circa
1993, an applications developer in a pure OO shop couldn't have tried
STL-like stunt in his business modeling. (I think.)

> I've written a couple essays on the subject of another way for OO and
> RDB to work together, based off, unfortunately, a concept of
> transactions. Unfortunate because the word transaction carries a lot of
> luggage with it that has little to do with what's really happening under
> the covers, and that's messages to the DB in the form of OO programs
> affecting state changes through DB stored procedures.

Will surely check them out, thanks.

Arne Vajhøj wrote:
> topmind wrote:
> > Before we get into the politics of Java, there is something ironic
> > about O/R wrappers like Hibernate: they are almost more complex than
> > the RDBMS itself. Thus, one is wrapping the DB with something that is
> > practically a DB engine *itself*. Is being married to Hibernate less
> > of a sofware engineering change-flexibility "sin" than being married
> > to Oracle or PostGreSQL? I never figured out the "logic" behind such.
> > It appears to be hypocritical to me. I compare it to hiding behind
> > Dracula to avoid being attacked by Frankenstein. Databases tend to
> > outlast languages, or at least are switched at roughly the same
> > frequency as languages. Thus, vendor-swap math doesn't seem to favor
> > it.
>
> It does if you are in the product business as opposed to
> the project business.
>
> Because then the resistance to change database actually
> favors tools that encapsulate the database specifics.
>
> Customer X may only buy your product if it runs on top
> of database A. They do not care what persistence framework
> you use to be able to support database A, B, C and D without
> changing the application code.

Databases are far more than "persistence" if you use them to their
potential. If you *only* treat it as a dumb filing system and do most
of the collection-oriented handling by building complex data
structures in app code, then you are reinventing the wheel. Many OO
designs seem to do this. Complex data structures (such as objects
pointing to objects) should not really be needed often if you use the
DB right.

Plus, you didn't answer the issue of trading marriage to a DB vendor
into being married to Hibernate. If the language carries its own
database engine (which is just about what hibernate is), then you
might as well ship the product with a specific RDBMS, such as MySql or
PostgreSQL to get a consistent DB engine.

>
> In cases like that a persistence framework is a real
> benefit.

If one more OO fan calls RDBMS "persistence" mechanisms, I will
personally bop them. File systems are "persistence mechanisms". RDBMS
are attribute managers, domain noun modelers, and they "encapsulate"
common collection-oriented idioms into a semi-standard tool, rather
than reinvent them from scratch like OO likes to do.

>
> Arne

-T-

On Apr 3, 9:37 pm, "topmind" <topm...{}technologist.com> wrote:

> It appears to be hypocritical to me. I compare it to hiding behind
> Dracula to avoid being attacked by Frankenstein.

:-)

> Databases tend to outlast languages, or at least are switched at roughly the
> same frequency as languages. Thus, vendor-swap math doesn't seem to favor
> it.

Is this really true? I believe switching of databases (assuming you
have zero stored procedures) would relatively be far, far less painful
than switching of languages, for rewriting code is non-trivial
compared to migrating raw table data. Because of this, if given a
choice, wouldn't you switch databases more frequently than languages?


> If you mean "go against the flow", there is indeed career problems
> with that.

I mentioned your OO-debunking site to another developer friend of
mine. And, so OO-brainwashed is he apparently that he's not even
willing to take a look, :-)


> I advise others to just go with the flow if you like money. You may have to
> choose between money and truth.

While I'll go for the money right now, will keep poking at the truth
in the background. I promise.

Harry wrote:
> On Apr 3, 6:52 pm, Thomas Gagne <tga...{}wide-open-west.com> wrote:
>
>
>> You're tongue-in-cheek suggests you don't buy that approach. I agree.
>>
>
> I do buy and, in fact, like most of his arguments on OO hype, noun-
> oriented class design issues, etc. However, in absence of real tools,
> API, (language support?) that encourage P/R style, you can't really do
> much, can you? Unless there's an industry-wide initiative to revive P/
> R mode of thinking, feeling, and acting a handful or two of ordinary
> developers (like myself) can't really go upstream... :-)
>
Regrettably, much of the Java code I've seen written in private industry
suggests Fortran can be written in any language.

Personally, our shop makes little effort to map our object data into our
database. There's just little need for it since we don't interact with
the DB that way. As the articles suggest, we communicate to the DB
through stored procedures, which may be peculiar to OLTP systems but
I've used the same approach with other applications (portfolio
management) without problem.

An advantage to interacting with the DB through stored procedures is the
strong analogy to how OO programmers are encouraged to interact with
their own objects with methods (message sends). Nearly as easy as
sending a message to an object to invoke some functionality or affect a
state change within that object we send messages to our database to to
invoke functionality and affect state changes within the DB.
> I don't have language designing / compiler writing skills myself, so
> can't really think in-depth / critically of all issues that would /
> could later surface in TOP for large scale, real-world projects.
> However, language designers (of major languages such as C++, Java,
> Perl, Ruby...) would already have these skills, and I hope they have
> considered TOP related arguments.
>
I'm unsure it's necessary since most languages are general purpose.
It's not language syntax that gets in the way but our (mis)conceptions
of the solution. If one pictures the application as a projection of the
DB's model or the DB as a projection of the application's model then
that's the solution they'll work towards--trying to reconcile a single
model across two very different representations with different and
not-always-complimentary natures. When programmers being struggling
with this reconciliation, even with the aid of O/R mapping tools and
multiple layers of abstraction, they suspect something may be amiss with
either OO or RD--but not their preconceptions.

So common is this problem that it's been given a name: the
object-relational impedance mismatch. Not everyone likes the name, but
they all grapple with it whenever they attempt to give objects the
responsibility to persist themselves into an RDB and instantiate
themselves from same.


--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

Harry wrote:
> On Apr 3, 9:37 pm, "topmind" <topm...{}technologist.com> wrote:
>
>
>> It appears to be hypocritical to me. I compare it to hiding behind
>> Dracula to avoid being attacked by Frankenstein.
>>
>
> :-)
>
>
>> Databases tend to outlast languages, or at least are switched at roughly the
>> same frequency as languages. Thus, vendor-swap math doesn't seem to favor
>> it.
>>
>
> Is this really true? I believe switching of databases (assuming you
> have zero stored procedures) would relatively be far, far less painful
> than switching of languages, for rewriting code is non-trivial
> compared to migrating raw table data. Because of this, if given a
> choice, wouldn't you switch databases more frequently than languages?
>
In my experience (24 years) I've never seen, visited, or consulted a
company that changed its database vendor. Of course, these companies
didn't have applications--they had systems. And each enterprise
database was accessed by applications written in multiple languages.

It was also the case that many of these companies had multiple
databases. The most common of which was DB2 and Oracle.

So the cardinality I've witnessed is really many-to-many
(languages-to-DB vendors).

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.