Geek asks and answers

DAO and Service layer design

I am developing a web application with Java EE 6. To minimize calls to the database, it would be nice to have classes:

The data access class (DAO) will call only the basic methods getAllClients, getAllProducts, getAllOrders, delete, update- CRUD methods.

A service class that will call CRUD methods, but optionally filtering methods, for example. findClientByName, findProuctByType, findProductByYear, findOrderFullyPaid/NotPaidetc., which will be based on the basic methods of DAO.

thank

0
source share
4 answers

In my experience (albeit limited), DAOclasses tend to have all the possible database operations that an application is allowed to perform. Thus, in your case it will have methods like getAllClients()and getClientByName(String name)etc.

DAO , , .

, , . ORM, Hibernate, , , .

EDIT:

, , . , , Service DAO. , , , DAO . , , public String getUserFormatted(String userName). getUserByName, DAO, .

Service , , - . - DAO Service.

, DAO ( CRUD), , DAO, DAO.

+6

, , , , , CRUD. , , , . , , , DAO...

/ , . , , , , , . , , , - , . , .

+3

, , DAO , .

findClientByName, findProuctByType, findProductByYear, findOrderFullyPaid/NotPaid DAO, - , , , , .

Imagine you have 10 years of data and you call findProductsByYear in your service class, and then you call getAllProducts and then discard 9 years of data in memory. It is much better for you to get your database in order to return to you only the year in which you are interested.

+2
source

Yes, this is the right way to do this.

The service will own the transactions. You must write them as POJO; that way you can open them as SOAO or REST web services, EJB or something else that you want later.

+1
source

More articles:


All Articles