• 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

Data Query Layer

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I want to build a lightweight and ultra fast data query layer (i.e. read only) and I have a few design related questions. First the rules of the game, this is strictly JDBC, and the use of Hibernate or other ORM frameworks is not acceptable (client rules). The layer will return simple ArrayLists of POJO data structures. This is for an HR system, so some example POJOs might be: Employee, Job, Salary, Department.

There will be at least one class that acts as the search provider for each POJO type. For example, I might design an interface IEmployeeSearchProvider that returns lists of Employee POJOs and would define multiple methods:

public interface IEmployeeSearchProvider {

public ArrayList<Employee> GetEmployeesByName();
public ArrayList<Employee> GetEmployeesByDepartment();
public ArrayList<Employee> GetEmployeesByManager();
public ArrayList<Employee> SomeMethod1();
public ArrayList<Employee> SomeMethod2();
public ArrayList<Employee> SomeMethod3();

}

Depending on what type of filters need to be applied to the data being retrieved, a given class implementation of IEmployeeSearchProvider could constrain the results appropriately. For example, class AllActiveEmployees would implement IEmployeeSearchProvider, and implement each of the methods such that only Active employees are returned.

The problem with this approach is that I'm defining mutltiple methods in the interface that search provider classes must implement even if they aren't interested in doing so. Throwing a MethodNotSupportedException in those cases when a class has chosen not to implement a given method seems like a hack. Surely there's a cleaner approach?
[ October 28, 2008: Message edited by: MitchieA ]
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"MitchieA", please check your private messages regarding an important administrative matter. You can check them here.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You should probably take a look at the Interpreter design pattern. It would allow you to have much fewer methods, by replacing something like

getEmployeesByNameAndDepartment(name, department)

by

getEmployees(and(byName(name), byDepartment(department)))

Can you tell us more about why you are not allowed to use an ORM framework???
 
Mitch Hartner
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the suggestion. I've seen lots of examples of Interpreter but none that are real world examples. Any suggestions?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mitch Hartner:
Thanks for the suggestion. I've seen lots of examples of Interpreter but none that are real world examples. Any suggestions?



Hamcrest basically uses the interpreter pattern for matchers: http://code.google.com/p/hamcrest/wiki/Tutorial
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe that, in the context of persistence layers, the Hibernate Criterion API might be worth looking at.
Since Hibernate's fully open-source you could sneak a peak at the source code as well.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jelle Klap:
I believe that, in the context of persistence layers, the Hibernate Criterion API might be worth looking at.



That's in fact another example of a use of the Interpreter pattern.
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Precisely. I thought it might be a more fitting example.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jelle Klap:
Precisely. I thought it might be a more fitting example.



Point taken.
 
Mitch Hartner
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks to all who replied.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic