CODEWITHSUNDEEP
javaspringdaospring-jdbc
ayan ahmedov
ayan ahmedov

Reputation: 391

DAO pattern in 3 level Architecture. How to deal with complex queries

I'm currently developing an application using 3 layers ui-service-dao . At the dao level I am using Spring's jdbcTemplate . So far so good but I encountered a situation which I like to have some more insight

My DAOs had at the beginnign only simple CRUD methods . At the service level I'm checking for input values and delegating to the DAOs and also dealing with transactions.

Now I need things more like this one below

List getAllBooksByAuthorName(String name)

My question is where to put this one? In DAO-layer using sql or in service by using core methods of CRUD and computing simply in java

I rather tend to use sql as much as possible instead of calculating at service layer. But now it seems like for every new method , I also need to change the interface of the DAO and make correspondent method in the interface of the service. Then service becomes nothing more than a delegator and parameter checker. It feels not right.

Upvotes: 3

Views: 2642

Answers (3)

Patrick Leitermann
Patrick Leitermann

Reputation: 2164

For example you could use the Entity-Control-Boundary-Pattern.

Your package structure will look like the following:

Under the namespace of your application you could introduce a package called "business", in that package there can be packages named by the business responsibility and these packages are seperated into "entity", "control" and "boundary".

com.example.myapplication.business.project.entity -> If you are using JPA all your entities can be stored in this package, contains DTOs

com.example.myapplication.business.project.control -> In this package refactored services can be stored, for example if the DAO-Code is needed in more than just one boundary, the code could be refactored in this package

com.example.myapplication.business.project.boundary -> This package contains all services that can be seen by the client (for example your web page)

In the package "presentation" your ui controllers can be stored and the ui controllers should only access the services stored in the boundary package.

com.example.myapplication.presentation.project

By using this pattern you avoid the use of delegators, because the services stored in the boundary-package can also contain sql-specific stuff and all servies and entities are in the package they belong to.

The pattern can be also used outside of JEE. Adam Bien has revolutionised this pattern in the JEE-Architecture and I´m using it also in my own projects. Here is an example -> http://www.youtube.com/watch?v=JWcoiXNoKxk#t=2380

The methods of your boundary could look like the following:

public interface ProjectService {
public Project createProject(Project project);
public Project getProjectById(String projectId);
public List<Project> getProjectList(ListConfig config); // where ListConfig is a class containing information of how the list should be sorted, optional pagination information, etc, so that the interface must not be changed every time you need a new parameter
public Project updateProject(Project project);
public void deleteProject(String projectId);
public Project addFeature(Project project, Feature feature);

}

@ayan ahmedov: Sorry, the first time I tried to answer your question I had unfortunately edit your question and my answer was in the content area of your question. I´ve 'reverted' the accidental changes.

Upvotes: 0

JB Nizet
JB Nizet

Reputation: 691735

That's however how it should be. In the business logic is reduced to nothing except calling a DAO method, then you are lucky to have simple business logic.

It would obviously be extremely inefficient and completely unrealistic to have the service call BookDAO.findAll() and filter the giant list of books returned by the DAO. SQL is the right tool for the job.

Note that the days where mocking was only possible with interfaces are past. Using an interface to define your DAO methods isn't really necessary anymore.

Upvotes: 2

gyanu
gyanu

Reputation: 995

Your opinions are quite valid but i didn't get much why you are in doubt.Generally DAO pattern reduce coupling between Business logic and Persistence logic.

public interface BooksDAO{
   public boolean save(Book book);
   public boolean update(Book book);
   public boolean findByBookIsbn(int isbn);
   public boolean delete(Book book);
   //here is what you want
   public List<Book> getAllBooksByAuthorName(String name);
}

Now you can have different implementations for BooksDao like HibernateBooksDaoImpl or JdbcBooksDAOImpl. DAO pattern makes easy to write isolated junit test and executes faster.

If you have complex queries you can still use dao pattern. Basically there is way to write complex queries in implementation side whether it is simple jdbc (sql can be used) or spring jdbc template(still sql can be used) or hibernate use criteria. see: http://docs.jboss.org/hibernate/core/3.6/javadocs/org/hibernate/Criteria.html

For more information look:

http://javarevisited.blogspot.com/2013/01/data-access-object-dao-design-pattern-java-tutorial-example.html
http://www.oracle.com/technetwork/articles/entarch/spring-jdbc-dao-101284.html

Upvotes: 2

Related Questions