Stability in a DAO API is highly desirable since it is an API between your domain/service layers and your persistence mechanism. The more stable you can make the API, the less disruptive changes to the implementations on either side of it will be to the other. If you design the DAO to deal with field-level values, your API and anything that depends on it will have to be changed much more often than if you made it deal with domain objects only. This is the benefit of encapsulation and abstraction.
BTW, you should settle on one spelling of 'employee' and stick to it. There are a number of instances in your code where you use 'employe'. Ideally, you would choose the correct spelling rather than try to save yourself a keystroke. Attention to these kind of small details is the mark of a good developer.
The solution you are using is having connection creation and usage in the method scope opening your code to wasteful connections instead of reuse, specially as the code grows bigger or one method calls another and all opening up connections.
You could use session/thread scoping of the connection for optimal usage and use DAO factories as described in the article below:
If this something you are doing for work, then I suggest you take a serious look at Spring Framework's DaoSupport classes, they make writing DAOs so much easier and you don't have to worry so much about "plumbing" issues like connections and pooling, etc. Let frameworks like Spring tke care of the plumbing, concentrate on the API and business logic.
Regarding the use of DAOFactory, I would be very careful about deciding to go with that approach. In most cases, you will only ever use one database so having a factory for DAOs is going to be overkill and will be more trouble than it's worth. Using dependency injection keeps your code much simpler while still keeping the door open to using a factory later on in the unlikely event that the need arises.
API-wise, it looks better. I would choose better names than 'insertData' and 'selectData' though. save(Employee), update(Employee), findById(int), find(Employee), delete(Employee) are some of the methods I would define for the basic DAO API.
Implementation-wise, I would not go to the extent of serializing/deserializing objects to/from the database. That approach kind of defeats the purpose of using a relational database to persist your objects. The DAO is responsible for marshalling/unmarshalling objects to/from a RDB. That is, it maps object attributes and relationships to the appropriate tables/columns when persisting objects to the DB and vice versa when materializing objects from the DB. You'd still have prepared statements and the like in the DAO. The usual implementation of a DAO is to take the domain object being passed and "disassemble" it so that attributes can be individually passed as parameters to appropriate SQL statements that perform the desired DB operations. On the flipside, when the DAO needs to materialize objects from the database, it performs appropriate "SELECT" statements, then uses the data in the result set to create objects as appropriate.
You really should work on choosing better names. See the difference between your code:
meeta gaur wrote:
Subtle differences but the second version does away with unhelpful names like 'obj' and 'employee1' - these just make understanding the code a little bit harder. Write code as if your computer-illiterate grandmother were going to read it.
Also, if you've defined a DAO interface, program against the interface, not a particular implementation.