I have spend some time to investigate the different concepts of
O/R-mapping, JDO and entity beans (EJB) for accessing relational
databases in java programming. I may be very conservative, but I can't
see that these tools reduces the time that have to be spent on doing
database programming. Of course, when you do SQL coding in the old
fashion way, you have to spend a lot of time doing simple insert,
update and select statements. But the other concepts adds extra things
to do or reduces the power of SQL.
Most O/R-mapping tools forces you to write both database DML, java
value objects and mapping descriptors. And mostly it introduces a
query language that is similar to SQL, but still something else, and a
accepted standard is missing. Why must java classes and tables be
mapped? Why can't java classes be generated from the database
structure?
JDO has not the concepts of relations (correct me if I am wrong) and
the query language seem to be very poor. When I look at the JDO API, I
miss most things that are good with relational databases. And I see
that I am not the first one to reject JDO.
It is a well known fact that entity beans (EJB) have a poor
performance and they don't reduces the time spent on writing SQL
statements, very much. Your either have to write JDBC calls (BMP) or
write SQL (or SQL-like) statemenents in descriptor files (CMP).
What I am missing is a object model on top of JDBC that reduces the
time you have to spend on simple SQL statements, but still gives you
the power to write complex queries. Why are there not a well-known API
that have Table class with the method findByPrimaryKey? This method
could return a instance of a Record class, with get- and set-methods,
and a save-method. With this a lot of boring work could be reduced. If
preferred, subclasses of this Record class could be generated for
every table, for making type-safe get- and set-methods.
In addition you should also have a Query class for expressing more
complex queries. All tools I have seen (except of S.O.D.A) uses
strings for defining query filters. Why?? It would be very simple to
make a Query object model for expressing a complex SQL select
statement.
Maybe I am the last one that thinks that the databases is an important
part of an application. And that the relational model is the
state-of-art concept of modeling data. Why all this talk about
converting the relational model to a object model. Make a object model
for accessing the relational model instead!
I have made a prototype on how a object model on top of the relational
model could look like (http://butler.sourceforge.net). Take a look if
you agree with me in the views above.
/Fredrik Bertilsson
brougham5@yahoo.com - 29 Dec 2003 01:24 GMT
>It is a well known fact that entity beans (EJB) have a poor
>performance and they don't reduces the time spent on writing SQL
>statements, very much.
As a blanket statement, that's neither a fact nor true.
Alex Chudnovsky - 19 Jan 2004 16:00 GMT
> Why all this talk about
> converting the relational model to a object model. Make a object model
> for accessing the relational model instead!
A Relational Model is not Object Oriented it is Relational.
An Object Oriented Language is Object Oriented.
The key point that I am trying to make here is that an Object Model
programmatically Models the real life domain problem, that is the beauty of
Object Oriented languages they let you Model real life objects
programmatically.
By having an 'Object domain model' model the database instead of the actual
domain problem totally defeats the purpose.
Perhaps your talking about just an object oriented way of dealing with the
database that would make sense perhaps something along the lines of Ofbiz
entity engine, but what I get is that your implying that you model the
database programmatically and to me that makes little sense.
Regards,
Alex Chudnovsky.
> I have spend some time to investigate the different concepts of
> O/R-mapping, JDO and entity beans (EJB) for accessing relational
[quoted text clipped - 48 lines]
>
> /Fredrik Bertilsson