ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick <ric...@gmail.com>
Subject A GenericDao ? and a few rambling thoughts...
Date Thu, 20 Aug 2009 15:17:02 GMT
According to the i3 docs it looks like for just a simple 'get' of a blog
you'd need something like:

Blog blog = null;
SqlSession session = sqlSessionFactory.openSession();
try {
    BlogMapper mapper = session.getMapper(BlogMapper.class);
    blog = mapper.selectBlog(id);
} finally {
  session.close();
}

That seems like way to much boiler plate code. In the past I've use Spring's
ibatis template (not out for ibatis3), the old ibatis DaoManager, or I
rolled my own BaseDAO that had utility methods to handle this and I could
just call:

Blog blog = (Blog)getSingleResult("BlogMapper.selectBlog", params );  //one
line

How would you see all this playing out in the new ibatis3 stuff? It would be
nice if ibatis3 came with it's own simple Dao to handle this kind of stuff
in a generic way, but I guess the issue would then be that you would lose
the leverage of BlogMapper.getById(id) types of calls (since Java doesn't
have closures.)

I'm actually working on a prototype project using iBATIS3 and I want to
follow some best practices, so I'm curious what you see as best practices? I
like the idea of the mapper classes, but not at the expense of it causing
the code be more bloated.

Another option is just push the getBlog to a BlogDao that you can call:

public class BlogDao {

    public Blog selectBlogById(int id) {
        Blog blog = null;
        SqlSession session = sqlSessionFactory.openSession();
        try {
            BlogMapper mapper = session.getMapper(BlogMapper.class);
            Blog blog = mapper.selectBlog(id);
        } finally {
          session.close();
        }
        return blog;
    }
}

But if I'm going to do the above, I don't even really need the BlogMapper
Interface since if all my "get" calls go through a dao, I'd only be defining
my map's sql name "selectBlog" in one place, so I really don't need the type
safety (since you'd only go through this dao to get a Blog.) However in
cases where I needed several calls in a transaction, I could see the
advantage, I suppose, of the clean BlogMapper.xzy calls - but is it that
much of an advantage over session.select(Blog.SELECT_BY_ID, id) - and not
even have a BlogMapper class?

Also, while I'm thinking of transactions, I think would be nice is some kind
of @Transaction demarcation, like you get with Spring, so you could just do:

public class MyService extends IBatisDaoTemplate {

@Transaction
public void doStuff() {
     getSession().select("Blog.getBlog", id);
     getSession().insert("foobar", fooparms);
     getSession().insert("doodie", blablaParms);
}

Possibly a SpringIbatisTemplate would handle this in the future, but it
would still be nice to not have to rely on Spring to get this kind of
functionality.

Mime
View raw message