ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Schatten <ala...@gmx.at>
Subject Modeling objects - Best practices wanted ;-)
Date Thu, 28 Dec 2006 18:21:45 GMT

o.k., I start with an apology for a lengthy email, but I am searching 
for some best-practices, that I could not find addressed properly, and I 
would like to get the ideas from the iBatis experts about "iBatis 
best-practices" in designing model/transfer objects:

Maybe I should start with an example to be concrete and get to the point 
(1): say, we have persons and projects, a project can have multiple 
persons assigned, and one person can work in multiple projects, hence a 
classical m:n relationship on database level.

Now my "simple" question is, how the iBatis experts would model this. I 
personally see (if I understand iBatis correctly) some options, I want 
to express to two "most radical" ones I see and ask for suggestions:

(the relational model is clear: one table PERSON, one table PROJECT one 
table PERSON_PROJECT containing references to PERSON and PROJECT.) O.k. 
lets move to the objects:

(Remark: the Java code here is mostly pseudo code for illustration)


(Option A)

Person and Project objects, both contain various "primitive" variables 
like "name, email, projectname" and so on. Now, the relation between 
projects and persons is modeled by a list in each object like so:

class Person {
   List<Project> projects;

class Project {
   List<Person> persons;

ok, now the problem starts. I additionally assume, that we have a DAO 
that should encapsule the database access (using Spring templates in the 
iBatis implementation). the DAO might look like so:

class IBatisPersonDAO implements PersonDAO {
   public Person getPerson(String email) {...}

When I call this method (and allow to directly access the lists, or via 
getPersons() accessor) what happens then? Several issues: again the most 
extreme (and obviously not desired one): the DAO goes recursively 
through persons and projects and returns the full tree of objects. This 
is obviously a bad idea, as this could potentially retrieve all persons 
and projects (not to mention the complexity in a more realistic 
example). So we can forget this one.

Now, Hibernate has a lazy load feature here (as far as I understand it), 
where you actually get a proxy object from Person back and this object 
loads the projects "on demand"; but this is problematic too; first the 
lazy load has to be configured properly (in a more complex setting...) 
and second, this only works as long as we have an established connection 
or you preload the stuff using appropriate hql statements...

ok, I think iBatis does not support such Proxy objects. What would be 
the solution then? I see several options: manually create such a proxy 
object and on getting the list of persons perform the actual SQL query 
using iBatis.

Alternatively, an option might be that this call to the DAO could be 
done in the Person object approx like so:

class Person {
   List<Project> projects;

  public List getProjects() {
      personDAO = spring.getBean("PersonDAO");
      return personDAO.getProjects(personID);


This would have the advantage, that only objects are loaded when they 
are needed, but the disadvantage, that I have a connection from the 
model/transfer object to the DAO, comments?? (Plus the issue: should the 
whole list of objects/person been loaded, what if this is a huge list...)

(similar problems arise with 1:m connections in principle)

Despite for all these issues also the saving is a logical problem. What 
happens when I call personDAO.save(person). Does it recursively check 
the project list on changes?

My argument here is, that when we model something like so, then it is 
not natural OO style anyway and the developer has to be "persistence 
aware", or it gets very complex in implementation, because after all, 
the OO developer has to keep in mind when and what to save by explicit 
calls. So is this probably just a "pseudo" OO model?


(Option B)

ok, I see a radical different implementation style: Person and Project 
object ONLY hold the primitive variables, no lists, hence are NOT aware 
by themselves, that there is a connection between them, however, I 
implement additional DAO methods like so:

class IBatisPersonDAO implements PersonDAO {
   public Person getPerson(String email) {...}
   public List<Project> getAssignedProjects(personId/email/...) { ... }

And vice versa in the Project DAO. What I like about this solution is, 
that both models stay very simple (the objects and the database schema 
plus the DAO logic), we have a clean decoupling between transfer 
objects/model and persistence technology. Everything that happens is 
clear and transparent: it is clear what is loaded, and it is clear what 
is saved and it is also clear in which object is loaded at what time 
(namely when the appropriate DAO method is used, not when the proxy 
object does something).
Currently I feel attracted to this option by the named reasons.

However, the clear drawback is, that we do not use OO "features" at all 
and this is just a bunch of flat transfer objects then without obvious 


Obviously there are some options in between these two and also some 
options more I would think. I am searching for what iBatis experienced 
developers feel are best-practices. I already search  for some time and 
practically found nothing of use. Book and Internet examples are 
typically trivial and do not really give a clue about a proper design 
here. Or they deal with inheritance, which is also an interesting 
problem field.But I feel that this is of utmost importance also for the 
documentation to lead newbies to a proper track!

(btw.: the iBatis manual mentions lazy loadings but actually never 
explains properly how to use it)

ok, this was very lengthy. Maybe still some iBatis experts have an 
opinion and would want to share it with me?

thank you very much in advance!


View raw message