我应该在mvc架构中实现特定的查询（spring + hibernate）？

Question

I'm implementing an enterprise application using spring mvc and hibernate. The application architecture is composed by the following layers:

• View
• Controller
• Service
• Domain
• Peristence

The data access is implemented with classic dao pattern and allows CRUD operations + generic queries. Where should I implement specific queries? I guess two solutions:

• implement specific queries in the service layer by creating hibernate criteria and passing it to the persistence layer
• implement specific queries in DAO classes by create a function for each query and call the functions in the service layer.

What should I do? Are there better solutions?

Answer 1

Service layer is a business layer and there must not be used any persistence provider related interfaces and classes (ie Hibernate Criteria API). That's a good practice - you can change your persistence provider without touching any line of code in your service layer.

Don't hesitate to go with your second option (implement specific queries in DAO classes).

Alternatively you can use kind of business dynamic query pattern which is mix of the query and builder pattern (like Criteria API). Here is the simple example:

interface CarQuery {
    CarQuery model(String model);
    CarQuery color(String color);
    List<CarQuery> execute(); 
}
....
List<Car> cars = carDao.getQuery().model("Jeep").color("green").execute();
....

You can implement HibernateCarQuery that can use Hibernate Criteria API internally. This surely requires some additional efforts but will not pollute your daos with specific methods if you're planning to use them extensively and need ability to build queries dynamically (typical case is multiple filters on UI pages).

Answer 2

From layered architecture perspective, the sql queries should not be used/declared outside DAO layer. You might have noticed that spring opted to use transaction on service layer since transaction is not the responsibility of DAO and you can also call it as resource leakage/cross cutting concern. Declaring /using sql queries apart from Dao will be considered to be resource leakage/cross cutting concern.

I would like to add something since you touched hibernate and criteria API. When you are using criteria then why should you need separate query? Criteria API is an elegant way to achieve persistence because it is perfect OO approach.

Answer 3

This:

• implement specific queries in DAO classes by create a function for each query and call the functions in the service layer.

DAO is shorthand for "Data Access Object" and one of the maim reasons to use the DAO pattern is to comply with the "Single Responsibility Principle". If you have some other classes in your code, other than the DAO classes, which handle Data Access, then you are violating the SRP and it becomes a more or less moot point to use the DAO pattern at all.

More importantly, for maintainability purposes, if other developers are going to maintain your code later on, and they see a bunch of DAO classes lying about, they are not going to expect data access to be happening anywhere else.

Your service layer isn't even supposed to have a dependency on Hibernate. Why would you have that? Your service layer should only depend on your domain layer, which in turn depends on your persistence layer, which is where your Hibernate dependency should be,

Answer 4

It is better to have all the queries in the DAO class methods and run them. If you are working on HQL, have all the queries written in the NamedQuery and access it by name at the run time.

Answer 5

I use to create a GenericDAO class and an IDao interface and all the other DAOs - let's say a ClientDAO - extends the Generic.

That being said, I create an interface that extends IDao (which have the basics methods like findAll() , delete() , save() )

Eg

IClient

public interface IClient extends IDao { 
   public void findWithWhere(String where);
}

ClientDaoImpl

public class ClientDaoImpl extends GenericDao<Client> implements IClient {

  public void findWithWhere(String where) {
   //do custom stuff here
  }
}

And then have a ClientDaoImpl object in the Controller (or Service) Layer
That may look a little tiring to do, but, for me, it keeps all the layers well divided and when I have to change a method (maybe receive a new parameter), I simple change the interface to know where I have to implement.