Alan Chandler wrote:
Hang on a sec here, don't we also map Java Classes to database tables
with iBatis? A User class
in my design maps to a User table in the database. Isn't this exactly
how the iBatis docs tell us
we should map our result beans?
Well
a) I was simplifying, but yes we map to beans not objects - but I have a
message that I want to get across
Hi Alan,
Instantiated beans are objects too, no? :) The point is that /once/
we start creating classes like these:
public class Student{
private Classroom classroom; <- another class
}
or
public class Classroom{
private List students; <- collection of students
}
... we get snookered into the ORM corner.
b) We do NOT map directly to tables, only to the results of a SQL statement
(which - as you say - might be a table). But the crux of my arguement is
that although for simple CRUD you might have that simple mapping, any real
application is more complex than that.
We have a 90 table data model where we began to model the bean
structures exactly as suggested by iBatis
documentation.
We then removed all such structures (refer above to the class examples)
and are now using the "dataset"
approach (with foreign-key links) - but this is very clumsy with
instances of beans in lists instead of dealing with
true-blue disconnected datasets. :-)
I disagree if you design your database with proper normalisation. In my
recent family tree application of the 12 SELECT statements only 2 mapped
directly to the table and 2 others half did (I added a dynamic where clause
to limit the search via a filter).
How many iBatis users design their beans like the example above?
Kind regards,
Abdullah
