• 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

Domain Object Queries

 
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I usually utilize a service layer between my controller and DAO objects.

An example DAO would look like this:



This is pretty simple. In fact, I could make it simpler by using an example object.



However, if I want to add 'cross context' functionality or different operators it becomes troublesome and results in lots of code duplication.



Writing a full blown query API would be nice, but would be an arduous task.

What tools / patterns are others using to approach this problem?


 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can design it in a way where it "does not" become troublesome. "Troublesome" areas stem from how "you" organize the code. You should attempt to avoid unnecessary code duplication with the understanding that it is ok to have duplicate code (you need to just identify a good reason for it.)
 
Kerry Wilson
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

James Clark wrote:You can design it in a way where it "does not" become troublesome. "Troublesome" areas stem from how "you" organize the code. You should attempt to avoid unnecessary code duplication with the understanding that it is ok to have duplicate code (you need to just identify a good reason for it.)



So you think it's fine to add two methods (one in the service, and one in the DAO) for every query?

I am not necessarily approaching it from a 'duplicate code is bad standpoint' as the amount of dupe code is likely to be minimal. However, I do try and minimize LOC, and creating 2 methods for every query is not very conducive to that end.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe you should rethink the way you have created the DAO query methods. Based on the method signatures that you have posted and indicated with the query method names, there are other ways to create these methods. Instead of having four methods to find books, only have one. Think about it.

The business methods and DAO methods should not match one-to-one. Your business methods most likely need to be more coarse and probably need to be restructured with emphasis on the "business requirement" facing up rather than "data oriented" and facing down.

Good luck!
 
Kerry Wilson
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

James Clark wrote:Maybe you should rethink the way you have created the DAO query methods. Based on the method signatures that you have posted and indicated with the query method names, there are other ways to create these methods. Instead of having four methods to find books, only have one. Think about it.

The business methods and DAO methods should not match one-to-one. Your business methods most likely need to be more coarse and probably need to be restructured with emphasis on the "business requirement" facing up rather than "data oriented" and facing down.

Good luck!



I tend to create my DAO methods to be lower level than my service layer classes. For instance, if I was returning a book I would query for it in the DAO and populate it in the service method. For instance, I might pull ratings for the book, or get additional information from a Web Service. However, this still doesn't escape the fact that a Domain Query API will be necessary (or many different methods at the service and DAO layers).

If you know of a better solution for this please post a link and/or example code.

Thanks
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A better solution for what? Your posts do no clearly describe a real "problem." You seem to be unsure about clearly separating business methods and data access methods.
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kerry Wilson wrote:
However, if I want to add 'cross context' functionality or different operators it becomes troublesome and results in lots of code duplication.



Writing a full blown query API would be nice, but would be an arduous task.

What tools / patterns are others using to approach this problem?


What you mean by cross-context? You know, I don't see any problem with your interface. For me it's absolutely alright.
I think the problem is your implementation. I recommend you to use iBATIS, implementing the above interface is a piece of cake.

But if I misunderstand your problem, please let me know. To be honest, I don't quite understand what the problem is.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I highly recommend you take a look a the Interpreter design pattern, using that, you could write code like



or alternatively

 
reply
    Bookmark Topic Watch Topic
  • New Topic