0

In my current job they are defining a new corporate architecture for java development. It is something like this:

  • ProjectView: JSF view layer. Uses delegates on the ProjectClient layer.
  • ProjectClient: Defines Delegates and Facades. It does de lookup for the EJBs the business layer.
  • ProjectBusiness: Implements the Facades defined by the client layer as remotes EJBs. It also containes the model and the DAO layer.

The business layer maps entities to DTOs so the client and view only knows about DTOs clases.

My concern

Let's say we have an entity Car with attributes horsePower, numberOfDoors, engineType and releaseDate. Now, we need in the view to search the cars with 3 doors and more than 120hp. With the initial vision of the architecture I should write the functions needed in all layers that take this to arguments.

But if I need with 3 doors and more than 120hp or diesel engine? The answer was: build another function. Thats one in the delegate, on the facade interface, the facade impl and in the dao.

But our entities don't have 4 fields. More like 30. IMHO is going to be chaos and people dying when we start writing full apps, with hundreds of functions all over the place. Changing the model is not an option.

My solution

I've created a prototype inspired in queryDsl to create dynamic queries from the view that follows the layer pattern so you could write something like this in a manager bean from JSF. Just one class needs to be created in the ProjectClient layer.

ClientQuery query = new ClientQuery();
QCar qcar = QCar.qcar;
query.and(qcar.model.eq(model)).and(qcar.horsePower.get(minumuHp));
return carService.searchCars(query);

The prototype keeps the layers separated and the dao layer can choose with query builder to use given a generic query.

My Question

This aproach makes sense? I haven't found anything on this subject so I am stating to think that maybe is an anti-pattern or some kind of bad practice. If it makes sense, is there any framework/library or pattern to look further?

I've uploaded the prototype to Github and can share the link if asked to.

0

In simple case you can use SearchCriteria dto:

class CarSearchCriteria {
   private integer horsePower;
   private integer numberOfDoors;
   private String model;
   // other needed parameters
   // getters/setters
}
CarSearchCriteria criteria = new CarsSearchCriteria()
    .withModel(model)
    .withHorsePower(minHorsePower);
return carService.searchCars(criteria);

In complex case you can use your dynamic queries (it is criteria design pattern)

In more than complex case dynamic queries won't help you. It will be more complex than sql called with facade method.

Look on the next extreme case. It is obviously a bad design to place such things in a view layer:

String sqlQuery = "SELECT * from Car where model = ? AND horsePower > ?"
Object[] params = new Object[] {model, horsePower} // your parameters
return searchService.searchEntity(query, params, Car.class);

But ask yourself: Do you really want to place your dynamic queries in a view layer?

  • My post was bou the Criteria aproach. I find it quite useful in search-like pages and the flexibility it gives to retrieve data from the view layer when no special or highly complex query is needed. Thanks for the criteria pattern link. I was missing that keyword in my search, as keyword "query" gets you SQL related results. – Guillermo Gefaell Oct 19 '15 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.