«

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

carmelo wrote:

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

--
Michal

Michal Kleczek wrote:
> carmelo wrote:
>> 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.

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.

> ...

>> What would be real advantages in addition to greater independence and
>> portability?

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.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg

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

Andreas Leitgeb wrote:
> 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.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg

On 23-03-2011 04:45, carmelo wrote:
> 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

On 23-03-2011 07:26, Michal Kleczek wrote:
> 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.

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

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

Arne

On 23-03-2011 09:57, Lew wrote:
> Michal Kleczek wrote:
>> 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.

That depends on whether the problem to be solved would
benefit from such.

>>> What would be real advantages in addition to greater independence and
>>> portability?
>
> 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.

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

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

On 11-03-23 05:45 AM, carmelo wrote:
> 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 ****

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