ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry Meadors" <lmead...@apache.org>
Subject Re: New to iBatis
Date Mon, 18 Jun 2007 04:38:05 GMT
Man, what a can of worms this is..but it's great to see someone asking
these questions up-front, so I'll give it a shot, then give you my
opinion.

You might want to get comfortable, this is a long one. :)

> With Hibernate, the entire data model is mapped out for
> the application, which can initially take a while and
> have a lot of configuration, but once complete, will
> allow the developer to access the update the data model
> as the application develops with any specific queries
> that they see fit, without adding any extra POJOS or
> configuration code.

This is partially true - yes, you will need to map all of your
database objects to your java objects. This is not a terribly onerous
task, because there are some decent code generation tools that do much
of it for you.

The part that may be misleading here is that as the data/object models
mutate, both sides must mutate in perfect synchronization because it
is a 1-1 match between your data model and your object model.

In addition, as you add or move fields in your data model or object
model, the option to auto-generate the mapping degenerates.

> iBatis, on the other hand, is much simpler to set up,
> but configuration and java code (POJOS and DAOS) will
> have to be added as more queries are added to the
> application because each result class will have to be
> specifically designed for the individual query.

I think iBATIS will be simpler to set up, and you will need to add
some XML and SQL for your application.

Not every query will require a bean, and I think that most iBATIS
users generally use it to map database objects to java objects in a
way that is similar to ORM. For example, in a system I am working on,
there are User and Customer and Order beans that match the database
fields.

However, in many cases, I just need to display information from
multiple tables, so I'll use a hashmap to fetch related data. It's a
fast and easy way to get data, and requires very little code
(essentially the SQL, and one line to run it).

I was an early adapter of ORM, and quickly learned that as my
application grew, and my data access needs moved beyond 'select * from
employee', I needed to write custom queries.

Using hibernate, I had to do that in Java code using either HQL (the
query language of choice for Hibernate), or SQL (which was translated
into HQL...then back to SQL to be executed). To create a query, I had
to concatenate strings to build my query right in my Java code. This
made it nearly impossible to optimize queries, because they were
embedded in a sea if if(){} blocks, and were not easy to extract and
run outside of the application. Because the SQL was all generated, it
made it very difficult to pass to a DBA for optimization. My DBA did
not like my application much.

Using iBATIS, I do that in an XML file using SQL. For complex queries,
I use dynamic SQL which allows me to do 99% of what is needed. I can
also take SQL to a DBA (or any other SQL smart person) and have them
help optimize it.

There are also cases where your database and object models *don't*
match perfectly. In one system that I am working on, there are some
non-trivial calculations that are used to determine prices based on
both the product and the customer - some customers get lower prices on
some products than others. For that reason, the base price of a
product is stored, but whenever we need to get an actual price, we use
a database function to get it, like this: select price(product.price,
customer.id).

So the price on my product bean is never the price stored in the
database, but always calculated. If we were forced to map the database
to the object model, this would require creating a table or view that
stored the price at the customer+product level. We would also need to
find a way to ensure that the price in that table was always correct.

That brings up my main complaint about ORM.

In every system that I have worked on in the last 20 years, there are
two statements that are invariably true:
1) the only value is in the data
2) the data will outlive the code

The systems that access business data only have value because they
simplify access to the real value, which is the data. The code without
the data is like a car without gasoline - a bright shiny pile of
useless parts.

With those two thoughts in mind, every single ORM tool that I have
ever used requires that I corrupt my database to fit the object model
because it will make development simpler.

To put that in different terms, they force me to decrease the value of
the only thing in the entire system that has intrinsic value (the
data) to  simplify the development of tools (the part with no value).

That's just a retarded idea.

Larry

Mime
View raw message