Well, ideally, you'd like to have your interfaces be unconcerned with how the thing is actually implemented behind the scenes. Whether we're actually saving the thing to a Database by JDBC, to a database by iBatis, or to an xml file shouldn't be refected in the interface. You have introduced a tiny little artifact of the implementation in the fact that your interface has to extend Dao.

I can see times you might want to package your interfaces in a separate package than the actual implementation along with the business objects that you are saving, reading, etc. You'd like that package to be as dependency free as possible. For example, a Client/Server type app over RMI might have a Client package, a Common package and a Server package, with the Dao interface in the Common package to be shared by both the client and the server package. Now, you've introduced a dependency on the iBatis Dao interface which requires us to have the iBatis jar in the client's classpath, when the client could care less that we're using iBatis behind the scenes on the server.

I'm not trolling here, just trying to understand how best to use this technology.