Re: ORM or JDBC?
On 03/24/2011 03:18 AM, Michal Kleczek wrote:
Arne Vajh??j wrote:
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.
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.
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.
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.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg