Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > ORM or JDBC?

Reply
Thread Tools

ORM or JDBC?

 
 
Arne Vajhj
Guest
Posts: n/a
 
      03-25-2011
On 24-03-2011 06:35, Michal Kleczek wrote:
> Lew wrote:
>
>> 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.
>>

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


No.

The use of ORM somewhat assume a separation between presentation
and data access layers.

The 1960's style of having everything in one big intertangled mess
does not fit well with ORM.

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


Two independent problems:
database -> in memory model
in memory model -> display
should have two independent pieces of code.

Arne

 
Reply With Quote
 
 
 
 
Arne Vajhøj
Guest
Posts: n/a
 
      03-25-2011
On 24-03-2011 03:18, 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.


????

You seem to forget that you save to write your own data access layer.

That is a huge benefit.

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

>
> Maybe. But what is a benefit of using ORM and data classes instead of
> ResultSet and databound GUI controls?


The code in the ORM is maintained by somebody else.

The code you write to get data out of the ResultSet is something
you have to maintain.

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


It is not a myth.

It is a fact that is observed every day in real life.

Arne

 
Reply With Quote
 
 
 
 
Arne Vajhj
Guest
Posts: n/a
 
      03-25-2011
On 23-03-2011 23:08, Lawrence D'Oliveiro wrote:
> Is JDBC worth using?


In practice any database access you do on Java will use JDBC.

The only question is whether you see the JDBC or it is hidden
in some higher level library.

In most cases a higher level librray is better to use, but in
some cases getting down to JDBC is necessary.

> I thought it was just a Java layer on top of ODBC.


No.

JDBC is an abstract abstract API.

There exist a so called JDBC-ODBC bridge that puts
a JDBC API on top of ODBC.

But that is just one out of many JDBC drivers.

And one that is rarely used outside of hello world
level.

> Which nobody in their right mind uses.


ODBC is actually a fine C API.

SUN's JDBC-ODBC bridge sucks.

Arne

 
Reply With Quote
 
Michal Kleczek
Guest
Posts: n/a
 
      03-25-2011
Arne Vajhøj wrote:

> On 24-03-2011 06:35, Michal Kleczek wrote:
>>
>> 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?

>
> No.
>
> The use of ORM somewhat assume a separation between presentation
> and data access layers.


They already _are_ separated. JDBC classes are designed to access data.
Swing (or any other widget library) classes are for presentation. They don't
have _anything_ in common.
To move data from one set of objects to another you can use ORM tool - the
problem is that ORM tools I know are not really helpful in this task.

>
> The 1960's style of having everything in one big intertangled mess
> does not fit well with ORM.
>
>> 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?

>
> Two independent problems:
> database -> in memory model
> in memory model -> display
> should have two independent pieces of code.


You seem to forget that "in memory model" of data stored in a database is
already implemented - it is abstracted as ResultSet/PreparedStatement.
Please - tell me what is the value of having _another_ "in memory
representation" just to move the data from ResultSets to GUI objects.

--
Michal
 
Reply With Quote
 
Michal Kleczek
Guest
Posts: n/a
 
      03-25-2011
Lew wrote:

> On 03/24/2011 06:35 AM, Michal Kleczek wrote:
>> Lew wrote:
>>
>>> Michal Kleczek wrote:

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


Of course - and they are not coupled - GWT widget library has nothing to do
with JDBC and vice versa.

> in the fashion you describe. Plus there is no framework such as you ask.
>
> Widgets display values of objects,


Don't know what a "value of an object" is.
Widgets display state represented by values of _their_ properties.

> not data tables.


True.

> Any framework that
> lets
> the widgets use your data has to translate the data into an object.


The data is already translated to an object (instance of a class
implementing java.sql.ResultSet) by a JDBC driver.

> That's what an ORM does


What ORM does (or shoud do) is it translates one representation of data (a
ResultSet) into another (user defined).
The problem is that existing ORMs fail to do it for arbitrary chosen class
models. Instead they force a programmer to define _another_ class model that
is suited for this particular ORM.
Some would call it "accidental complexity". Others: "tail wags the dog".

> , and that's what you will have to do by hand if
> not with a framework.


I have to do it by hand anyway because I have to translate the data from one
representation (a ResultSet) to another (a Widget or it's subclass or in
case of Swing to JComponent or its subclass).
I cannot see how existing ORMs (JPA included) can help me with this.

--
Michal
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      03-25-2011
In message <4d8bf9d8$0$23757$(E-Mail Removed)>, Arne Vajhøj wrote:

> In practice any database access you do on Java will use JDBC.


JDBC doesn’t seem to be supported on Android.

> The only question is whether you see the JDBC or it is hidden
> in some higher level library.


I am using SQLite3 directly.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      03-25-2011
In message <imer88$u0v$(E-Mail Removed)>, Michal Kleczek wrote:

> Arne Vajhøj wrote:
>
>> 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.


And so we go back and forth in the eternal argument. There is a fundamental
“impedance mismatch” between relational databases and object-oriented
programming, and nigh-on 20 years of arguing about it has still failed to
come up with a proper solution. Trying to introduce object-oriented
databases didn’t work.

Basically, databases are a pain to work with in Java.
 
Reply With Quote
 
Michal Kleczek
Guest
Posts: n/a
 
      03-25-2011
Lawrence D'Oliveiro wrote:

> In message <imer88$u0v$(E-Mail Removed)>, Michal Kleczek wrote:
>
>> Arne Vajhøj wrote:
>>
>>> 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.

>
> And so we go back and forth in the eternal argument. There is a
> fundamental “impedance mismatch” between relational databases and
> object-oriented programming, and nigh-on 20 years of arguing about it has
> still failed to come up with a proper solution.


To be honest I don't think there is any special "impedance mismatch" between
OO programming and relational databases. It is not different than let's say
a mismatch between OO and functional or logic programming. It is just that
some problems are easier to solve in different paradigms and a properly
architected system makes use of this fact and integrates various parts
together. I guess it is just a matter of perspective.

Sure - it would (probably) be better to have a single multiparadigm
language. Such languages exist but are not widely used (Oz is one such
example). Looks like the industry is heading towards this direction with
efforts such as Scala.
On the other hand such a language has its drawbacks as well - the main is
that it is multiparadigm (what a paradox) - so there is no single, coherent
way of creating software in such a language.

> Trying to introduce
> object-oriented databases didn’t work.


And that is because so called object-oriented databases actually do not
provide a key feature that a database (or rather DBMS) is supposed to
provide which is _sharing_ data (and not just persistence for a singe
application).
The whole OO-RM "impedance mismatch" has its roots in trying to use RDBMS as
a mere persistence mechanism for a OO application.

>
> Basically, databases are a pain to work with in Java.


I don't find working with databases painful at all and I guess a lot of
people (whether they use ORMs or not) would agree with me.

--
Michal
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      03-25-2011
Michal Kleczek wrote:
> What ORM does (or shoud do) is it translates one representation of data (a
> ResultSet) into another (user defined).
> The problem is that existing ORMs fail to do it for arbitrary chosen class
> models. Instead they force a programmer to define _another_ class model that
> is suited for this particular ORM.
> Some would call it "accidental complexity". Others: "tail wags the dog".


I would call that "misinformation". ORMs can turn any data model into any
object model that you can do with JDBC.

Why do people keep making these false statements "JPA cannot do X"? It's very
irresponsible to give people such false information, even unethical.

Lew said:
>> , and that's what you will have to do by hand if
>> not with a framework.


Michal Kleczek wrote:
> I have to do it by hand anyway because I have to translate the data from one
> representation (a ResultSet) to another (a Widget or it's subclass or in


But you have to do it with more code and tanglement with raw JDBC generally
than with the boilerplate-saving and neatly-separated way that JPA does.
There is a difference. The JPA approach, properly applied, reduces effort and
risk involved in mapping a data store to your object model.

> case of Swing to JComponent or its subclass).
> I cannot see how existing ORMs (JPA included) can help me with this.


Too bad for you, then.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      03-25-2011
Michal Kleczek wrote:
> You seem to forget that "in memory model" of data stored in a database is
> already implemented - it is abstracted as ResultSet/PreparedStatement.
> Please - tell me what is the value of having _another_ "in memory
> representation" just to move the data from ResultSets to GUI objects.


You seem to forget that 'ResultSet' and 'PreparedStatement' are not
domain-model types.

If they are, well, then OF COURSE you don't need JPA. JPA is designed to
translate table models into DOMAIN models.

Since for some bizarre reason you don't have a need for a domain model
(whaa...?), why would you even consider an ORM?

Good programmers, who use domain models, would see value in JPA.

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

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
modeling--DAO vs ORM Tom Java 1 01-14-2006 07:41 AM
ORM Chris Kennedy MCSD 0 09-06-2005 03:09 AM
Dejavu 1.3, a Python ORM Robert Brewer Python 0 01-21-2005 07:08 AM
Dejavu 1.2.6, a Python ORM Robert Brewer Python 0 12-16-2004 12:09 AM
ORM resources necessary for 70-300 TomTom MCSD 7 08-17-2004 07:08 AM



Advertisments