ORM or JDBC?

[Arne Vajhøj]

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.

Questionable claim since most Java apps does use databases. Somehow
people does not seem to consider it a pain.

Arne

 

[Arne Vajhøj]

To be honest I don't think there is any special "impedance mismatch" between
OO programming and relational databases.

It has been well known for something like 20 years.

It is not different than let's say
a mismatch between OO and functional or logic programming.

The fcat that other problem exists does not make a problem go away.

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

????

OODBMS'es support multiple apps.

Some even support multiple apps in different languages.

Arne

 

[Arne Vajhøj]

JDBC doesn’t seem to be supported on Android.

It is.

http://developer.android.com/reference/java/sql/package-summary.html

I am using SQLite3 directly.

Very unusual.

And unless there are some specific reasons not to use JDBC
in Android a very bad idea.

Arne

 

[Lawrence D'Oliveiro]

What does it prove?

That you are wrong.

 

[Lawrence D'Oliveiro]

Questionable claim since most Java apps does use databases. Somehow
people does not seem to consider it a pain.

Have a go at this example, then
<http://groups.google.co.nz/[email protected]>, and
see how the Java version compares.

 

[Arne Vajhøj]

That is your opinion. You appear to have a positive attitude towards ORM
tools while I don't. You think it is worth the trouble (as in effort) to
get your ORM to use the mapping you want for the benefits it will give
you in other areas while I usually don't (yes, I use the word "usually"
deliberately here because although I dislike ORM tools in general I
don't consider them a poor choice in all cases, just like I know you
don't consider them silver bullets).

Lew is not the only one with that opinion.

ORM is the standard today in the Java world and plain JDBC the
exception.

I have seen several projects in big trouble because even TopLink (and in
one case Hibernate) experts could not get the mappings just right to get
the system to behave properly on oddly (not to say poorly) structured
databases.
In all but one of these projects parts of the database access was
rewritten to go around the ORM.

It is also my experience too that ORM work best with databases created
with ORM in mind and not quite as well with databases designed for
other usages in mind (like COBOL in the mid 1980's).

But I don't blame ORM for those problems.

Arne

 

[Arne Vajhøj]

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.

It was you that asked for something to map between the database
and your widgets.

And I answered that:
- ORM does not work in that context
- I don't consider that a problem since it is very bad design

You seem to forget that "in memory model" of data stored in a database is
already implemented - it is abstracted as ResultSet/PreparedStatement.

A ResultSet is not in memory and are severely limited in functionality
and support mainly simple data types. A PreparedStatement does
not even contain data.

Please - tell me what is the value of having _another_ "in memory
representation" just to move the data from ResultSets to GUI objects.

That should be covered in basic software design.

You decouple the presentation layer from the persistence method
used.

You can cache data.

And probably a lot of other good things.

Arne

 

[Arne Vajhøj]

I think we start to talk past each other but let me try again.
Swing _is_ a DOMAIN model - it models a domain of GUI.

No.

A domain model is a pure data model of the data you a are processing
independent of how it is displayed and stored.

Look up the definition in PEAA.

Or try Wikipdia:
http://en.wikipedia.org/wiki/Domain_model

I need to "map" two DOMAIN models - accounting database schema and Swing. Is
JPA going to help me with that. If so - may I ask for some
tutorials/articles/examples?

No - you have a GUI and a database - we are suggesting to you that
in many cases it will be beneficial for you to put a domain model
in between.

Arne

 

[Arne Vajhøj]

My program does not _model_ anything. It fulfils requirements.

Modeling your domain is a key concept in OOD/OOP.

If you are not using OOD/OOP, then you wil not ant ORM.

I am also skeptical about whether Java is the right choice of language.

That is exactly my point. My program is supposed to provide a GUI so that a
user can enter/modify data in a particular accounting database managed by a
RDBMS. So it's domain is _not_ accounting but user interface and
communication with RDBMS. There is no single line of code related to
accounting in it (and there should not be because this is not the purpose of
this program).
Part of classes in my program is related to UI because this is what this
program is supposed to do. Another part of my program is made of classes
that are related to communicating with RDBMS - again - because that is what
my program is supposed to do.
The fact those classes are off the shelf (both JDBC and Swing) is not
relevant.

You are operating on data for accounting.

You should use an accounting domain model.

It would help the structure of your code.

But more importantly: you should go through a business
logic layer that implements accounting rules.

Directly editing data in an accounting database without
going through accounting business logic comes with a risk
of bring the data in an inconsistent state.

And it is also illegal in many jurisdictions.

I am more and more convinced it is not me who does not understand what
domain and domain model is

You have beyond any doubt proved that you don't know what a domain model
(or that you use a definition that is different from what everybody
else uses, which in reality is the same).

Arne

 

[Lew]

It cannot do the latter without doing the former.

The statement is ludicrous on its face. That's like saying a musician doesn't
play themes and melodies, he plays notes specified by sheet music.

Modeling your domain is a key concept in OOD/OOP.

If you are not using OOD/OOP, then you wil not ant ORM.

I am also skeptical about whether Java is the right choice of language.

or whether programming the right choice of profession.

Arne's good advice:

You are operating on data for accounting.

You should use an accounting domain model.

It would help the structure of your code.

But more importantly: you should go through a business
logic layer that implements accounting rules.

Directly editing data in an accounting database without
going through accounting business logic comes with a risk
of bring the data in an inconsistent state.

And it is also illegal in many jurisdictions.

Which ones?

That is an absolutely fascinating legal theory implied there.

Lew advised:
Then you are progressively more ignorant. Reverse that direction.

 

[Lew]

No.

A domain model is a pure data model of the data you a are processing
independent of how it is displayed and stored.

Look up the definition in PEAA.

Or try Wikipdia:
http://en.wikipedia.org/wiki/Domain_model


No - you have a GUI and a database - we are suggesting to you that
in many cases it will be beneficial for you to put a domain model
in between.

Nichal, you are consistently hearing that you're asking for something that
doesn't exist, and is an antipattern. All you do is argue with what we're saying.

If you already know everything then you don't need anyone else's help.

 

[Lawrence D'Oliveiro]

It is.

http://developer.android.com/reference/java/sql/package-summary.html

No drivers, though.

Very unusual.

Only way to do it.

And unless there are some specific reasons not to use JDBC
in Android a very bad idea.

See above.

 

[Lawrence D'Oliveiro]

It is also my experience too that ORM work best with databases created
with ORM in mind and not quite as well with databases designed for
other usages in mind (like COBOL in the mid 1980's).

Relational databases are designed with the data semantics in mind
(normalization and functional dependence, referential integrity etc),
nothing more. Things like ORM have to do with the limitations of Java, they
have no place in database design.

 

[Arved Sandstrom]

No.

A domain model is a pure data model of the data you a are processing
independent of how it is displayed and stored.

Look up the definition in PEAA.

Or try Wikipdia:
http://en.wikipedia.org/wiki/Domain_model

I don't want to get embroiled in this particular sub-thread, but I feel
compelled to point out that neither of those two links, nor common
usage, suggests that a domain model is a "pure data" model. Domain
models, as the articles indicate, incorporate both behaviour and data.

A "pure data" model, I suggest, is something that you're dealing with
during physical design of your data representation and storage (*).

[ SNIP ]

AHS

* So _not_ an ERD either. These are conceptual just like domain
models...in fact ERDs _are_ also domain models.

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

 

[Michal Kleczek]

It was you that asked for something to map between the database
and your widgets.

Since the app is supposed to display data from the database this "mapping"
(for lack of a better word) is unavoidable, don't you think?
The question is not _if_ you need it but "how to implement it?".

And I answered that:
- ORM does not work in that context

I read it "in the context of implementing GUIs that display data from a
relational database ORM is useless".

- I don't consider that a problem since it is very bad design

My design in the context of this discussion is ( an arrow means "depends
on"):
[JDBC and database schema] <--- X ---> [GUI library]

X being something of our interest in this thread.

What is wrong with this design?

[snip]

That should be covered in basic software design.

You decouple the presentation layer from the persistence method
used.

Again - they are decoupled - see above.
Or maybe we define "coupling" differently.

You can cache data.

True.
OTOH you can cache data using other means as well - for example by having a
caching JDBC driver on top of a "real" one (a decorator pattern). You don't
need ORM to cache data (since they are orthogonal concerns).

And probably a lot of other good things.

What are they?

 

[Michal Kleczek]

Nichal, you are consistently hearing that you're asking for something that
doesn't exist, and is an antipattern.
All you do is argue with what we're
saying.

If you already know everything then you don't need anyone else's help.

I didn't ask for help. I am discussing - thought discussion groups are for
er... discussions. If you do not want to discuss - just don't reply - it's
that easy.

 

[Lew]

Since the app is supposed to display data from the database this "mapping"
(for lack of a better word) is unavoidable, don't you think?
The question is not _if_ you need it but "how to implement it?".

You mean the /discussion/ is about how to implement it. After all, as you so
helpfully pointed out, you aren't asking for help, you're having a discussion.
Right?

Several people have addressed that matter in this thread but I haven't seen
you reply to their points yet.

I read it "in the context of implementing GUIs that display data from a
relational database ORM is useless".

Hadn't replied until now, that is, but one might suggest that you really
aren't contributing to the discussion much with that reply.

My design in the context of this discussion is ( an arrow means "depends
on"):
[JDBC and database schema]<--- X ---> [GUI library]

X being something of our interest in this thread.

What is wrong with this design?

This discussion is getting boring. You argue with everyone without really
showing that you understand what is said, you ignore some of what people say
that is relevant, you deny that you want help but you keep asking for help.

You ask questions that appear to be sincere requests for information or
opinion, only to make replies to show off how wrong the entire rest of the
newsgroup is. When someone tries to engage you in the conversation, rather
than reply to the points you say, "If you do not want to discuss - just don't
reply - it's that easy." Why would you be so rude if, as you claim, your goal
is to engage in discussion?

To answer your question, there isn't enough information in the question to
deem anything wrong with the fragment of design you show.

The actual things you've asked for, some magic third-party library to break
encapsulation and the innate MVC model of the libraries in question in order
to directly couple the things you ask about in a way they never intended,
don't exist, as many folks have already told you several times. I guess you
weren't listening. Please, Oh Great Master of Programming, write your own.

 

[Lawrence D'Oliveiro]

Directly editing data in an accounting database without
going through accounting business logic comes with a risk
of bring the data in an inconsistent state.

And it is also illegal in many jurisdictions.

What is their legal definition of the “accounting business logic†layer,
then, if not the code that is doing the “direct editing†of the accounting
data?

 

[Silvio]

Lew is not the only one with that opinion.

ORM is the standard today in the Java world and plain JDBC the
exception.

I am not sure who defines what "the standard" is but you may be right.
But I do not find that an argument in favor of ORM on its own. EJB has
been considered the standard for years and I try to avoid them as much
as possible also.

I am doing different things than most people, I guess. But that is what
most people will say...

It is also my experience too that ORM work best with databases created
with ORM in mind and not quite as well with databases designed for
other usages in mind (like COBOL in the mid 1980's).

But I don't blame ORM for those problems.

Me neither. I just said that in such cases an ORM could very well be a
poor choice.

I rarely write database access code that targets specific tables or
table structures. For my purposes a RDBMS is just one of several types
of data sources for analysis and reporting. It may also be a type of
data storage system.

Generic database access code is not something that is supported very
well by ORMs, IMHO.

Silvio

 

[Lawrence D'Oliveiro]

I rarely write database access code that targets specific tables or
table structures. For my purposes a RDBMS is just one of several types
of data sources for analysis and reporting. It may also be a type of
data storage system.

What an odd thing to say. The whole point about relational databases is that
their structure is supposed to reflect the innate logical structure of the
data you’re dealing with—the actual semantics of your business app. To want
to abstract away from that would be to abstract away from the very details
of your business.