• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DAO design pattern

 
Ranch Hand
Posts: 305
Tomcat Server Notepad Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
Could you check my program, does it follow DAO design pattern or not ?

tHANKS.



 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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: https://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.
 
Greenhorn
Posts: 19
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 305
Tomcat Server Notepad Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 305
Tomcat Server Notepad Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you, it was simple i made it complex.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 305
Tomcat Server Notepad Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you, i got lesson, it should be easier for readers.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic