There’s something to be said about simplicity…
import org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;
import roadrantz.model.Motorist;
public class IBatisRantDao extends SqlMapClientDaoSupport
implements RantDao {
public Motorist getMotoristById(long id) {
return (Motorist) getSqlMapClientTemplate().
queryForObject("getMotoristById", id);
}
public void saveMotorist(Motorist motorist) {
getSqlMapClientTemplate().insert("saveMotorist", motorist);
}
}
You have hidden the complexity in the XML file
But yeah, it is simpler than hard coding it into the Java code. But Hibernate/Spring is just as simple.
Yep… if not simpler. I have been going through the Spring In Action book today, basically covering the chapters on persistence and transactions. I am really liking Spring/Hibernate3 annotations.
Oh, that’s supposed to be simple? You have a class named like an interface with a bunch of SqlMapClientTemplates?
Wouldn’t real simplicity be:
Motorist m = new Motorist(3);
m.ChangeSomething(“Blah”);
m.Save();
?
(Just sad I can’t rib you all in person anymore)
Cory
Well, it’s as simple as you’re going to get in java. I’ve never been a fan of using ActiveRecord in java though… always feels dirty. And all I would be doing is hardwiring the calls to the dao directly within the domain object, or passing the dao interface in via a constructor or setter.
Either way, I’ve always it’s a violation of SRP to include both data store access and domain logic in the same entity.
Heh… I actually didn’t notice that the “I” was in front of it. I don’t prefix my interfaces with the letter I… the implementation of the interface just happened to use iBatis.