ORM or JDBC?

C

carmelo

Hi everybody,
I would like your opinion regarding the use of ORM in web applications
built with GWT. I'm a little reconsider about the ORM, and I wonder
whether it is worth to use in web applications built with GWT. What
would be real advantages in addition to greater independence and
portability?

Waiting for your comments :)
 
M

Michal Kleczek

carmelo said:
Hi everybody,
I would like your opinion regarding the use of ORM in web applications
built with GWT. I'm a little reconsider about the ORM, and I wonder
whether it is worth to use in web applications built with GWT.

It depends on many things but IMHO the most important is "Do you have a rich
domain object model?" (and by "rich" I mean you have a lot of important
processing in your OO code - not just getters and setters).
If your app is only a way to manipulate (add/update/delete) data in a
database then I would strongly suggest _not_ using any ORM. It would only
add a lot of Java and/or XML/whatever code without any real benefit.

Sure - you will need a framework of some kind. But IMO it shoud be a generic
RDBMS oriented data transfer and maybe GUI/data binding one. (Similar to
SmartGWT for example).
What
would be real advantages in addition to greater independence and
portability?

Why do you think ORM gives you greater independence (from what?) and
portability? Are you going to port your app to a non-relational DBMS?
 
L

Lew

GWT is a graphical user interface library, right? What possible influence on
the choice of persistence architecture could that have?

Or am I wrong about GWT?
It depends on many things but IMHO the most important is "Do you have a rich
domain object model?" (and by "rich" I mean you have a lot of important
processing in your OO code - not just getters and setters).

If not, go back and develop one before proceeding.

Now we can proceed in the certainty that you do have one.
If your app is only a way to manipulate (add/update/delete) data in a
database then I would strongly suggest _not_ using any ORM. It would only
add a lot of Java and/or XML/whatever code without any real benefit.

"A lot"? No.

Certainly no more than the JDBC code you'll need instead.

And "without any real benefit"? Where do you get this stuff?

The real benefit, even for small projects, is the clean and manageable
conversion between data and object models, and a natural mapping of
relationships to collections.

Those aren't even advantages of an ORM.
Why do you think ORM gives you greater independence (from what?) and
portability? Are you going to port your app to a non-relational DBMS?

Portability is an overrated aspect of ORMs, but "relational DBMS" is no
guarantee of portability. When even the Oracle RDBMS deviates from the SQL
standard, and don't even get me started on MySQL, you can bet "relational"
won't help. But so what? How often have you had to change database systems
in a project?

The advantage of an ORM is to present a persistent object model to an
application and to relieve the application of boilerplate datastore-access
code. It doesn't do quite as well for bulk, or set-oriented operations, which
after all are the stock in trade of the relational model. In practice you'll
need mostly ORM code (that is, regular object code) and some "raw" JDBC,
depending on the mix of operations in your process.

I don't have any idea what "Michal" means by a "rich domain object model" that
could be something you wouldn't have regardless, so that's a red herring. You
need an object model. Period. It needs to be as "rich" as the domain you're
modeling. So take that comment as advice to have such a model, not as a
decider on the ORM question.

If you do use an ORM, use JPA (Java Persistence API)! Don't make the mistake
of using older specifications (e.g., "classic" Hibernate). The Oracle Java EE
tutorial has good information on how to do that. You can use Hibernate (in
its JPA mode!), EclipseLink (the /de facto/ reference implementation) or
Apache OpenJPA.

The problem with ORMs is that people use them as mere data-access libraries.
BRAAHHHHH! Wrong.

Use them to maintain an object model, not a data model. There are subtleties
to things like EntityManager lifetime and scope that flow naturally from an
object orientation, but will completely screw up your application (as I've
seen on multi-million-dollar projects) if you think of an ORM as a sort of
expanded JDBC.

A few measly hours of study should keep you out of the worst trouble.
 
A

Arne Vajhøj

I would like your opinion regarding the use of ORM in web applications
built with GWT. I'm a little reconsider about the ORM, and I wonder
whether it is worth to use in web applications built with GWT. What
would be real advantages in addition to greater independence and
portability?

The choice of framework for presentation layer should
not affect the choice of framework for data access layer.

If:
- your usage of data is typical CRUD of single objects
- your app is well above hello world complexity
then ORM is probably a good choice.

Arne
 
A

Arne Vajhøj

It depends on many things but IMHO the most important is "Do you have a rich
domain object model?" (and by "rich" I mean you have a lot of important
processing in your OO code - not just getters and setters).

What??

Most ORM data classes are pure data classes.
If your app is only a way to manipulate (add/update/delete) data in a
database then I would strongly suggest _not_ using any ORM. It would only
add a lot of Java and/or XML/whatever code without any real benefit.

What??

Together with queries then these are the areas where ORM are good.
Why do you think ORM gives you greater independence (from what?) and
portability?

Most ORM's handle the database specific stuff without the developer
needing to know.

Arne
 
A

Arne Vajhøj

If not, go back and develop one before proceeding.

That depends on whether the problem to be solved would
benefit from such.
Those aren't even advantages of an ORM.

It is certainly possible to write an ORM that does not
provide database independence, but all the major ones
for Java do provide it.
Portability is an overrated aspect of ORMs, but "relational DBMS" is no
guarantee of portability. When even the Oracle RDBMS deviates from the
SQL standard, and don't even get me started on MySQL, you can bet
"relational" won't help. But so what? How often have you had to change
database systems in a project?

It happens.

And it can be bloody expensive.
I don't have any idea what "Michal" means by a "rich domain object
model"

"rich" and "anemic" domain models are standard concepts - that
is either invented or at least propagated by Fowler.
that could be something you wouldn't have regardless, so that's a
red herring. You need an object model. Period.

That period should be a continuation mark.

The world is a bit more complex than that.

Fowler discusses it a bit in PEAA "Domain Model" "When to Use It".

There are also the frequent case of a non object centric
usage - think statistics and aggregation.

Arne
 
A

Arved Sandstrom

Hi everybody,
I would like your opinion regarding the use of ORM in web applications
built with GWT. I'm a little reconsider about the ORM, and I wonder
whether it is worth to use in web applications built with GWT. What
would be real advantages in addition to greater independence and
portability?

Waiting for your comments :)

For me this is a surprisingly difficult recommendation to make. For most
of the decade I've been using primarily ORMs - either Hibernate or
Toplink with native APIs, or for the past 3-4 years Hibernate or Toplink
Essentials/EclipseLink with JPA. Before that, in the Java/J2EE world, it
was JDBC. I've also used iBatis/MyBatis, and raw JDBC even recently.

After the past 3-4 years of using ORMs with JPA, mostly JPA 1.0 but some
JPA 2.0, on applications of moderate load (100-300 concurrent users) and
moderate complexity (200-300 entity classes), I've come to the following
conclusions:

1. For small applications it doesn't matter what you use: JDBC, a
non-JPA mapper like MyBatis, or a full-fledged ORM with JPA like
Hibernate or EclipseLink. All of them will work, with about the same
amount of effort, and none will be more problematic than any other;

2. For larger applications I can't in all good conscience recommend
full-fledged ORMs with JPA anymore unless it's:

a. in that subset (whether it's 10 percent, or 25 percent, or whatever)
of large applications that have persistent objects and usage patterns
that are well-served by JPA (*);

b. you have a team of persistence layer developers who have substantial,
hard-earned experience with all of - the target database, JDBC, the
target application server, and the specific chosen ORM. There are dozens
of ways to get bit with JPA ORMs, and sooner or later every one of them
will get you. You'll see exceptions and encounter problems that you will
never have with JDBC.

So I'm not discounting JPA ORMs completely - I simply don't think they
are an automatic first choice. Unfortunately you (or someone on your
team) needs to have significant experience with a large JPA project
before you know whether it's a reasonable choice. It's not possible -
IMHO - to make a general recommendation that favours JPA.

AHS

* this sounds like a circular objection, but it makes more sense once
you've gone through the agony of using JPA on a large project that
really doesn't benefit from it...or is actively hindered by using it.

--
That's not the recollection that I recall...All this information is
certainly in the hands of the auditor and we certainly await his report
to indicate what he deems has occurred.
-- Halifax, Nova Scotia mayor Peter Kelly, who is currently deeply in
the shit
 
L

Lawrence D'Oliveiro

Is JDBC worth using? I thought it was just a Java layer on top of ODBC.
Which nobody in their right mind uses.
 
M

Michal Kleczek

Arne said:
What??

Most ORM data classes are pure data classes.

Exactly my point - if that is the case then maintainig those classes and ORM
mapping code just adds cost without giving any benefits.
Been there done that, no thanks.
What??

Together with queries then these are the areas where ORM are good.

Maybe. But what is a benefit of using ORM and data classes instead of
ResultSet and databound GUI controls?
Most ORM's handle the database specific stuff without the developer
needing to know.

I would say that's a myth. There is no way one can create a system that is
using RDBMS without knowledge about relational databases.
 
S

Silvio

Hi everybody,
I would like your opinion regarding the use of ORM in web applications
built with GWT. I'm a little reconsider about the ORM, and I wonder
whether it is worth to use in web applications built with GWT. What
would be real advantages in addition to greater independence and
portability?

Waiting for your comments :)

If you consider the database a serialization/deserialization tool for
your domain objects than an ORM might be your best choice.

If the database is a deliverable on its own that will be used by other
applications, either custom or standard stuff like reporting, analytical
processing, ETL ..., or is pre-existing for similar reasons, then an ORM
is usually more trouble than its worth.
 
D

Donkey Hottie

Is JDBC worth using? I thought it was just a Java layer on top of ODBC.
Which nobody in their right mind uses.

Sun's JDBC-ODBC bridge is what you say. It is just one driver for JDBC.

JDBC itself has nothing to do with ODBC, and does not need or use it.
Native so called "thin" drivers are used mostly. The connect to the
database directly.

--

Q: Why don't Scotsmen ever have coffee the way they like it?
A: Well, they like it with two lumps of sugar. If they drink
it at home, they only take one, and if they drink it while
visiting, they always take three.
 
M

Michal Kleczek

Lew said:
GWT is a graphical user interface library, right? What possible influence
on the choice of persistence architecture could that have?

Or am I wrong about GWT?


If not, go back and develop one before proceeding.

Now we can proceed in the certainty that you do have one.

Right. IOW - you _always_ have an object model when programming in Java
(since it is OO language). So take an example:

Let's say the purpose of an app is to allow the user to manipulate data in a
general ledger database (managed by a RDBMS).
My object model is GWT widget library (a set of classes implementing user
interface).
Do you know of any ORM tool that will allow me to "map" one to another?

Or maybe you are saying I should design and develop _another_ class library
(an object model) and then design and develop _two_ mapping libraries (one
of them possibly based on some ORM tool) to achieve the goal?
 
A

Andreas Leitgeb

Lew said:
Andreas said:
Lew said:
carmelo wrote:
I would like your opinion regarding the use of ORM in web applications
built with GWT. ...
GWT is a graphical user interface library, right?
Or am I wrong about GWT? [...]
http://lmgtfy.com/?q=GWT
;-)
Good one!
It was a rhetorical question, though.

I for myself wouldn't have called GWT a GUI-lib, but that may be due
to an insufficient understanding of GWT or a differing definition of
"Gui-library" on my side.
Anyway, that's why I didn't see your answer as being rhetorical.
 
R

Roedy Green

I would like your opinion regarding the use of ORM in web applications
built with GWT. I'm a little reconsider about the ORM, and I wonder
whether it is worth to use in web applications built with GWT. What
would be real advantages in addition to greater independence and
portability?

Waiting for your comments :)

You might enjoy my comments at
http://mindprod.com/jgloss/sql.html#ALTERNATIVES
Also http://mindprod.com/jgloss/pod.html

Now with 64-bit Java and giant cheap VM, you might even do a project
without any POD at all, just serialise everything every once in a
while for backup. That would give you something very fast, but hard to
change.
 
L

Lew

Lew said:
Andreas said:
Lew wrote:
carmelo wrote:
I would like your opinion regarding the use of ORM in web applications
built with GWT. ...
GWT is a graphical user interface library, right?
Or am I wrong about GWT? [...]
http://lmgtfy.com/?q=GWT
;-)
Good one!
It was a rhetorical question, though.

I for myself wouldn't have called GWT a GUI-lib, but that may be due
to an insufficient understanding of GWT or a differing definition of
"Gui-library" on my side.
Anyway, that's why I didn't see your answer as being rhetorical.

Ooh, goody! I have an opportunity to learn something. (Clicking on the
LMGTFY link you thoughtfully provided.)

Thank you.
 
L

Lew

Right. IOW - you _always_ have an object model when programming in Java
(since it is OO language). So take an example:

Let's say the purpose of an app is to allow the user to manipulate data in a
general ledger database (managed by a RDBMS).
My object model is GWT widget library (a set of classes implementing user
interface).
Do you know of any ORM tool that will allow me to "map" one to another?

Or maybe you are saying I should design and develop _another_ class library
(an object model) and then design and develop _two_ mapping libraries (one
of them possibly based on some ORM tool) to achieve the goal?

No, but it is an antipattern to couple graphical widgets directly to the data
in the fashion you describe. Plus there is no framework such as you ask.

Widgets display values of objects, not data tables. Any framework that lets
the widgets use your data has to translate the data into an object. That's
what an ORM does, and that's what you will have to do by hand if not with a
framework.

You call that "two mapping layers". That isn't accurate. GWT is written to
use objects. You map the data into the objects that it uses, using any JPA or
other ORM tool, or via raw JDBC. That's only a single mapping.
 
L

Lew

Exactly my point - if that is the case then maintainig those classes and ORM
mapping code just adds cost without giving any benefits.
Been there done that, no thanks.

But it is the right thing to do despite your objection.

JPA adds significant benefit in the most common use cases for it.
Maybe. But what is a benefit of using ORM and data classes instead of
ResultSet and databound GUI controls?

Databound GUI controls are not part of GWT that I can quickly find, and they
are not as flexible in some ways as the GWT/AWT/Swing approach. These latter
are based on separation of Model and View (and Controller), a strong best
practice. With ORMs you don't have to pick column by column out of a
ResultSet and manually copy the data into a domain object (or widget). With
ORMs you construct your logic thinking in terms of object model (i.e., domain
model) and the relationships from the domain. The boilerplate to handle
persistence is abstracted away from the object manipulation, making for
cleaner, more maintainable code. (If you use it right, as with any library.)
The risk of error is reduced. The speed to working code is greatly increased.

So reduced risk, easier coding, enhanced productivity and use of best practices.

I would say that's a myth. There is no way one can create a system that is
using RDBMS without knowledge about relational databases.

True. But the ORM separates that knowledge into its own layer so that it
doesn't commingle with or corrupt the object-oriented layers of the code.

The imnpedance match between the ORM stuff and the rest of the application is
much better than between SQL and the rest of the application.

I've implemented the exact same apps using JDBC, monolithic DAOs with JDBC,
and with JPA. The JPA approach was the cleanest, most compact and easiest to
create of the three.
 
L

Lew

If you consider the database a serialization/deserialization tool for your
domain objects than an ORM might be your best choice.

If the database is a deliverable on its own that will be used by other
applications, either custom or standard stuff like reporting, analytical
processing, ETL ..., or is pre-existing for similar reasons, then an ORM is
usually more trouble than its worth.

Bullshit.

Besides the fact that you are vague about "usually", "trouble" and "its
worth", others' experience is the exact opposite.

JPA ORMs work great on existing databases used by multiple functional units.
They save a tonne of trouble and add very little, if properly approached.
They provide great worth. You can very quickly get to the object model needed
by the functional unit off any data source, shared or not, whether that model
differs from other consumers of the data store or not. It saves you
boilerplate, cleans up separation of layers, and smooths the core logic of an
application to use JPA.

Why would a database's pre-existence have any negative effect whatsoever on
the value of an ORM?

If anything, JPA's value is all the greater in that scenario. You focus one
set of effort on getting the mapping right, a separate set on the logic, you
actually get increased parallelization of work in a team, especially across
all those multiple consumers of the data.

That is not to say that every functional unit would use only JPA. It has
limits. Just not the ones you said.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,756
Messages
2,569,533
Members
45,007
Latest member
OrderFitnessKetoCapsules

Latest Threads

Top