Re: Mixing P/R philosophy with OO (within J2EE). : JDBC JAVA

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.

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, 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.

> 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.

The level of standardization in SQL is rather high. If you skip using
stored procedures and use ANSI SQL 92, entry level, you can switch
database rather painless.

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

If you only use a RDBMS for persistence, then it would obviously be
very easy to switch, with or without frameworks, because you are only
using 5% of the features.

/Fredrik

frebe wrote:
> > 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.
>
> The level of standardization in SQL is rather high. If you skip using
> stored procedures and use ANSI SQL 92, entry level, you can switch
> database rather painless.

It seems the vendors' documentation tends to "trick" one into using
their proprietary syntax and functions, downplaying the standard
approaches. I've found it hard to find documentation on writing vendor-
neutral SQL. (The ANSI documents are not very human-friendly and
require lots of coffee.)

>
> > In cases like that a persistence framework is a real benefit.
>
> If you only use a RDBMS for persistence, then it would obviously be
> very easy to switch, with or without frameworks, because you are only
> using 5% of the features.
>
> /Fredrik

-T-

On Apr 3, 8:55 pm, "topmind" <topm...@technologist.com> wrote:
> 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.
Yes, it is much less of a sin. Since you are picking on Hibernate I
will use that as the example. Hibernate is transparent persistence
for the business objects. I want my application to be independent of
the data source, since data can come from more places than the disk
store. So my business logic is not coupled to the RDBMS. Also,
Hibernate is not 'practically a DB engine *itself*.' It is a tool that
aids in letting my business objects be saved. It has none of the
attributes of a DBMS at all.

> > > 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
Data outlasts applications. Databases and languages change seldom. The
whole point in using ORM is to make use of the data that is available
in a timely fashion without requiring a change or addition in the
database. The domain model for the application may be different from
that of the database, so having an agile mapping system makes sense.
Applications change often, business rules change even more often.
Database change is slow and methodical and can be traumatic if not
handled carefully. We do not want to put frequently changing logic
into the DB, we want to put data into the DB.

> > > 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.
Absolutely

>
> > 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 the case of Java (since that is the language we are talking about)
using a good DAO pattern, it is quite easy to switch the DB interface
layer. Much easier than switching DB's. But that argument is, IMO, a
red herring. I don't see DB switching as an issue. Because data is
such a huge company asset, the DBMS tends not to change. The real
benefit of ORM is that it allows easy use of relational-modeled data
in an OO language.

>
>
>
> > 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"
The relational model is not the domain model. It is a construct that
is mapped to a domain model. It happens to be mathematically sound
and very good at certain operations that conform to the underlying
math, and many of the implementations have done excellent jobs of
efficient storage, security and management of the space. That is what
they are good at. But don't tell me that the model as implemented in
the DB is THE MODEL. In fact, I would argue that a good OO Domain
Model is a better candidate for being THE MODEL than the relational
model. It has less restriction and more flexibility to reflect the
domain than the relational has. That does not mean that we throw the
relational model away, it means that it is another tool in our
developers' tool box that we use when appropriate.

An RDBMS *is* a persistence mechanism. It is a very good one. It is
a bad place to put application code and business logic. An OO program
is a good place to put application code and business logic. It is not
reinventing the wheel, it is using a tool for the purpose it is best
suited. In fact, doing it all in the DB is a case of the 'Golden
Hammer'.

> common collection-oriented idioms into a semi-standard tool, rather
> than reinvent them from scratch like OO likes to do.
>
>
>
> > Arne
>
> -T-

gryphon_smg wrote:
> On Apr 3, 8:55 pm, "topmind" <topm...@technologist.com> wrote:
> > 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 thatis
> > > > 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.
>
> Yes, it is much less of a sin. Since you are picking on Hibernate I
> will use that as the example. Hibernate is transparent persistence
> for the business objects.

Again, if you are using the RDBMS as ONLY a dumb object dumping
ground, then you may be right. However, many of us think it is a good
idea to use the RDBMS to its fuller potentially rather than reinvent
database idioms in app code and build ugly navigational structures
with a bunch of set/get red-tape on top.

> I want my application to be independent of
> the data source, since data can come from more places than the disk
> store.

RDBMS are not about disks. SQL is an *interface*. Hiding from one
interface (SQL) by using another (Hibernate) simply *trades* one
dependency for another, NOT rids net dependencies.

> So my business logic is not coupled to the RDBMS. Also,
> Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> aids in letting my business objects be saved. It has none of the
> attributes of a DBMS at all.

It is complicated middle-ware with some quasi-DB qualities.

>
> > > > 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
>
> Data outlasts applications. Databases and languages change seldom.

Then why the obsession with swapping?

> The
> whole point in using ORM is to make use of the data that is available
> in a timely fashion without requiring a change or addition in the
> database.

Use of app-specific tables, views, and/or databases is not forbidden.
If your DBA does not allow it, then that is an issue of internal
politics. Using objects to create a mini app-specific RAM database is
dumb in my opinion unless as a last resort. OO is crappy at managing
bunches of links between objects, creating navigational spegghetti
which is the Goto of the 2000's.

> The domain model for the application may be different from
> that of the database, so having an agile mapping system makes sense.
> Applications change often, business rules change even more often.
> Database change is slow and methodical and can be traumatic if not
> handled carefully. We do not want to put frequently changing logic
> into the DB, we want to put data into the DB.

Queries and Views are another technique to map the shared data to app-
specific or task-specific views.

> > > 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 the case of Java (since that is the language we are talking about)
> using a good DAO pattern, it is quite easy to switch the DB interface
> layer. Much easier than switching DB's. But that argument is, IMO, a
> red herring. I don't see DB switching as an issue. Because data is
> such a huge company asset, the DBMS tends not to change. The real
> benefit of ORM is that it allows easy use of relational-modeled data
> in an OO language.
>

If swapping vendors is not the issue, so then what exactly *is* the
problem with using direct queries in the app?

> >
> > > 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"
>
> The relational model is not the domain model. It is a construct that
> is mapped to a domain model.

Horsecrap. It is as much the domain model as a bunch of classes. This
is paradigm bias. (I will agree that some forms of "behavior" are best
at the app level, but this does not take away the general domain
modeling ability since we usually want most behavior at the app
level.)

> It happens to be mathematically sound
> and very good at certain operations that conform to the underlying
> math, and many of the implementations have done excellent jobs of
> efficient storage, security and management of the space. That is what
> they are good at. But don't tell me that the model as implemented in
> the DB is THE MODEL.

Maybe 70% of it.

> In fact, I would argue that a good OO Domain
> Model is a better candidate for being THE MODEL than the relational
> model.

Prove it. Show the code of it being better.

> It has less restriction and more flexibility to reflect the
> domain than the relational has.

Prove it. I agree that the "big iron" view of RDBMS popularized by
Oracle is sometimes restricting, but in a flexible organization it
does not have to be. "We use OO because our DBA is stubburn and slow"
is perhaps understandable, but is that the full justification?

> That does not mean that we throw the
> relational model away, it means that it is another tool in our
> developers' tool box that we use when appropriate.
>
> An RDBMS *is* a persistence mechanism.

Noooooo! Persistence is one of many aspects of a RDBMS. You OO'ers
have an obsession with disks.

> It is a very good one. It is
> a bad place to put application code and business logic. An OO program
> is a good place to put application code and business logic. It is not
> reinventing the wheel, it is using a tool for the purpose it is best
> suited. In fact, doing it all in the DB is a case of the 'Golden
> Hammer'.

So OO is the Golden Hammer? I don't think so.

>
> > common collection-oriented idioms into a semi-standard tool, rather
> > than reinvent them from scratch like OO likes to do.
> >
> >
> >
> > > Arne
> >

-T-