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 ]