File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes DAO design pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "DAO design pattern" Watch "DAO design pattern" New topic
Author

DAO design pattern

meeta gaur
Ranch Hand

Joined: Dec 05, 2012
Posts: 305

Hi
Could you check my program, does it follow DAO design pattern or not ?

tHANKS.





My one regret in life is that I am not someone else.
- Woody Allen
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4991
    
    8

Not an ideal design. You are using the DAO for fine-grained, field level operations. DAOs are more stable when they deal more with coarse-grained, domain object level operations. See my example of a PersonDao in this thread: http://www.coderanch.com/t/604205/java/java/Refactoring-Method

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.


Junilu - [How to Ask Questions] [How to Answer Questions]
Rommel Sharma
Greenhorn

Joined: Oct 31, 2003
Posts: 18
Hi Meeta,

You could consider using a DataSource instead and take advantage of connection pooling:
http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html


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:

http://www.oracle.com/technetwork/java/dataaccessobject-138824.html


Thanks,
Rommel.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4991
    
    8

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.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4991
    
    8

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.
meeta gaur
Ranch Hand

Joined: Dec 05, 2012
Posts: 305

Thank you very much to correct me.I'm re-posting my new code, this time i performed operations on object rather than fields as you told.This time am i correct ?

ij> create table employee(id int,data blob);
0 rows inserted/updated/deleted


1 row(s) affected
Id: 1 Name: nikita
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4991
    
    8

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.
meeta gaur
Ranch Hand

Joined: Dec 05, 2012
Posts: 305

Thank you, it was simple i made it complex.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4991
    
    8

You really should work on choosing better names. See the difference between your code:
meeta gaur wrote:



and this:



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.
meeta gaur
Ranch Hand

Joined: Dec 05, 2012
Posts: 305

Thank you, i got lesson, it should be easier for readers.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: DAO design pattern