• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Business logic with Spring: services or DAO

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I’m writing in Spring in conjunction with Hibernate and every time I need to write access DB I face the same question:
where to place business logic?
Of course it is recommended to put it to services and keep DAO as simple as possible (the best to keep DAO only for CRUD). But what in the case when I would like to retrieve, let’s say Bookings. But only those with status ACTIVE (it means, that field status equals ACTIVE and additionally validFrom is LT today and validTo is GT today).
It will give me more complex query which I place in DAO method: List<Bookings> findActiveBookings()
So far so good.

Now let's assume that ACTIVE is also that booking which has status RESERVED and validTo date equal today.

I have two possibilities:

1) extends my DAO method and make SQL more complex at the same time putting some business conditions into DAO (if ACTIVE and date=..., if RESERVED and date=...)
OR
2) create another method List<Booking>findReservedBookingForDate() and in services call them both and aggregate the results.
(of course it is worth to consider creating more generic method for example List<Booking> findBookingForState(BookingState state))

Which approach is better: keep simple DAO and move logic to services but have more DB access OR have one DB access but more complex query in DAO


Thanks in advance for your opinions.

 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's better to have complex queries in DAO because generally speaking, the database is better at processing complex queries than code that you can write. Plus, doing aggregation/filtering in the service tier requires you to send a lot of data over the network from database to the app server, which would reduce throughput.


Remember that the main reason you want to put all your business logic in the service layer is to make it maintainable and easier to understand. So, as far as I'm concerned, all the if conditions and the for loops related to business logic should be in the service layer. It's fine if your DAO is doing filtering, as lo as the DAO methods are very concise. You should be able to look at the service implementation and know what the application is doing. It's fine if you DAO has more than basic crud methods.



 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic