Article:		iBatis DAO
Subject:		Why extend Dao?
Date:		2005-09-26 12:48:41
From:		adamkrieg
Is it me or is this whole exercise pointless if your Dao interface needs to extend iBatis's Dao interface? Your Dao interface should have no dependencies on iBatis or color me unimpressed. Or am I missing something?

Showing messages 1 through 4 of 4.

• Why extend Dao?
  2006-07-08 18:45:19  Fucema [View]
  
  
  Strictly speaking, you are using IBatis DAO as your DAO layer. You are not extending or combining your existing DAO with Ibatis DAO.
  
  IBatis DAO is meant to substitute having to hand code your own custom DAO API.

• Why extend Dao?
  2005-09-27 06:08:10  SunilPatil [View]
  
  
  Dao is marker interface.
  Not sure what do you mean by it should not have any dependency on iBatis.
  
  Sunil
• Why extend Dao?
  2005-09-30 07:06:37  adamkrieg [View]
  
  
  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.
• Why extend Dao?
  2006-07-08 18:42:14  Fucema [View]
  
  
  Most companies or developers end up writing their own lightweight DAO layers. In those cases they are going to have to distribute their custom DAO API anyways. In the case of Ibatis DAO, you are using a premade DAO layer so you will be sharing that API. In either case, you will have a DAO layer that will have some dependencies. You will have to distribute youre DAO API whether you write your own DAO or use iBatis DAO (which is different from iBatis SQL Mapper).
  
  <quote>Well, ideally, you'd like to have your interfaces be unconcerned with how the thing is actually implemented behind the scenes.</quote>
  That's the point of having a DAO layer - whether its IBatis DAO or something you write on your own, you are abstracting the actual persistence implementation. Perhaps you are getting the IBatis DAO confused with the IBatis SQL Mapper.
  
  <quote>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.</quote>
  The IBatis is just the DAO layer -- you would some sort of DAO implementation at that level whether you use IBatis or roll your own. So I don't see what your point is.
  
  The benefit to using IBatis DAO is that you have access to a pretty robust implementation that allows you to swap in different persistence implementations behind the scene. It's all about code reuse wherever possible, at least for me. And IBatis has alot of advantages in that area. Why rewrite a DAO layer everytime you start a new project at a different company or contract.