3

I know the title of this question is not very descriptive, but I didn't know how to better explain the question...

I'd like to know your opinion about a doubt that arised during the implementation of a DAO class.

I'm implementing a CustomerDAO class that must provide access to related data in my application DB. I've implemented the classic CRUD methods as usual, but now I need to implement some method providing data retrieved used "specific" queries.

I mean something like:

SELECT [...] FROM CUSTOMERS WHERE <CUSTOMER_PROPERTY_1> = 'X' AND <CUSTOMER_SOME_DATE> > ? AND <CUSTOMER_SOME_DATE> < ?

So my question is, what's the right approach or "best-practice" to follow? Implement many specific methods like getCustomersByXPropertyBetweenDates() or try to generalize query and implement a more "generic" (not in Java-sense) method?

Note I'm using plain JDBC and JdbcTemplate provided by Spring Framework v 3.1

davioooh
  • 23,742
  • 39
  • 159
  • 250
  • Did you consider named queries? – RP- Jun 11 '12 at 09:27
  • @Rp- what's the actual advantage of using named queries? can I use them also with JDBC? – davioooh Jun 11 '12 at 09:33
  • @davioooh no you can't, its not applicable to this problem (spring and jdbcTemplate), they are used in jpa and hibernate etc and allow a query to be defined on the domain object. Bit overrated imho. – NimChimpsky Jun 11 '12 at 10:19
  • 1
    I'd say being "specific" is the point of having a DAO layer in the first place - it's the layer that *specifies* the how to meaningfully access (including looking up or querying) data. You want to hide the complexity of writing SQL by replacing it with a simpler API, instead of a different complex (-ish) generic API. – millimoose Jun 11 '12 at 11:35
  • @Inerdial Yes, I completely agree with you, so I'll implement "specific" methods. Thank you very much for your interesting comment! – davioooh Jun 11 '12 at 12:53

3 Answers3

1

How would you make the query you listed "generic" ? Also, bad choice of word.

I would just have the separate queries, separate. Don't try and do anything clever, you have a specific query keep it simple don't try and fit in around another query.

If you want properly generic I'd suggest using an ORM.

Community
  • 1
  • 1
NimChimpsky
  • 46,453
  • 60
  • 198
  • 311
  • For the reason explained in this question http://stackoverflow.com/q/10427441/1061499 i cannot use an ORM. When I say "generic", I mean a more general (maybe still a bad choice of word) query... So the implemented method can be more reusable... Hope it's clear enaugh... – davioooh Jun 11 '12 at 10:09
  • @davioooh oh my, that link sent a shudder down my spine, that is bad imho. Its clear what you want, but how would write the code to make the query you listed fit into a more generalized form ? My point is you won't without a lot of work. For what gain ? Just keep the queries separate, unless it really is quite simple to make them "fit". – NimChimpsky Jun 11 '12 at 10:12
  • 1
    So I think that I'll go for several specific methods. Trying to implement generalized methods maybe I'll just compicate things, obtaining only some kind of "Inner-platform-effect", do you agree with me? – davioooh Jun 11 '12 at 10:40
  • Yes. I have recently had to gone back to this type of dao layer (as opposed to an ORM), its actually quite nice to use. Simple, everything is where you expect it to be, no other dependencies, simple sql - no long if statements used to create sql where clauses. – NimChimpsky Jun 11 '12 at 10:45
0

I think it is more business driven decision. If you have separate business operations related to different methods, you could create the specific methods. If you have business operation "advanced search form" with pack of fields for search criteria, it has more sense to create a special "query" entity class with the form data, which will be then converted into a sql query by DAO implementation.

Also, please have a look at the query dsl, it may simplify a lot of the DAO layer.

kan
  • 28,279
  • 7
  • 71
  • 101
0

Implement an abstract DAO class which defines/implements methods common(CRUD) to all the DAO's. Define business methods in specific DAO interfaces and implement in DAO classes.

public interface IDAO< T extends Serializable>{

   T save( final T entity );
   T update( final T entity);
   void delete( final long id );
   void deleteAll();
   T findOne( final long id );
   List< T > findAll();

}

public abstract class AbstractDAO< T extends Serializable > implements IDAO< T >{




protected abstract JdbcTemplate getTemplate();


protected abstract T save(T entity);

    ...

}

customer DAO interface will define business specific methods

public interface ICustomerDAO extends IDAO<Customer>
{
   public List<Customer> findDormantCustomers();

}

customer DAO implementation will look something like below.

public class CustomerDAO extends AbstractDAO<Customer> implements ICustomerDAO{

public Customer save(Customer customer){
   getTemplate().insert(...);
   return customer;
}

    public List<Customer> findDormantCustomers(){
       ...
       return;
    }
}
FFL
  • 669
  • 7
  • 22