Pagination Handler Design advice

Original Problem: one of the SQL queries in my application returns a large resultset. Instead of sending the whole resultset to the client app, I have added changes to return finite number of rows based on User Input.

Solution: This is a classical problem and found numerous resources on the web which were useful. I have already created a class which will read the user page request and return only a finite no of rows.

Problem: There are other parts of my application which could also have a similar problem. So, I thought of designing an abstract Pagination handler and have designed it as follows:

class PaginationHandler{

/**

* Returns only a finite number of rows based on user requested page.

*

*@param pageRequested page requested by the user

*@param daoClassName name of the DAO class

*@param daoMethodName name of method to be invoked in the DAO class

*@param argListToDAOMethod arguments of the DAO method

*@param classTypeofArgs class types of args to the DAO method

*/

publicstatic Page getPage(int pageRequested, String daoClassName, String daoMethodName, Object[] argListToDAOMethod, Class[] classTypesOfArguments)

{

Class daoClass = Class.forName(daoClassName);

Method method = daoClass.getMethod(daoMethodName, classTypeofArgs);

/**

* code for setting up DAO method to return finite number of rows goes here which is 3-4 lines of code.

*/

// finally invoke the DAO method which returns a finite list

List pageList = (List) method.invoke(dao, argListToDAOMethod);

}

}

// from my business class, i will call this method as follows

someMethod()

{

// let's assume in my EmployeeDAO class, I have a method that returns a list of all employees. Also, the method takes a String andinteger as params.

Object[] obArray =new Object[2];

ob[0] = location;// string

ob[1] = age;// integer

Class[] classArray =new Class[2];

classArray[0] = String.class;

classArray[1] = int.class;

PaginationHandler.getPage(10,"com.ibm.software.EmployeeDAO","getEmployeeList", obArray, classArray);

}

The code above works fine. However, my major hearburn is due the fact that I will need to pass the arguments to the DAO method as an Object array since it could vary from one method to the next. Also, if some of the arguments are null, then, I cannot determine the classtype from within my PageHandler method. Hence, I need the Class types of all the arguments.

So, I am contemplating whether to copy this function into each Business class and customize it there and not worry about code duplication since, forcing the caller to send an array of class types looks awkward.

Any input will help.

Jawahar

[3477 byte] By [Jawahar_m2003a] at [2007-10-2 12:24:03]
# 1

Why aren't you using OO techniques? Are you more comfortable in functional languages because this is a very functional approach. The problem is that Java is not a functional language.

It appears to me that you will create a new DAO instance on each call unless there is a static (global, really) DAO which is a bad idea in itself.

Couldn't you just pass an instance of the DAO with the parameters already set to your Paginator? Do you have a DAO interface?

dubwaia at 2007-7-13 9:15:59 > top of Java-index,Other Topics,Patterns & OO Design...
# 2
I am planning on passing the DAO object as a parameter to the function. I missed that part. However, I didn't understand your comment "DAO with the parameters already set". Could you please tell me what you mean by this comment.Thanks.
Jawahar_m2003a at 2007-7-13 9:15:59 > top of Java-index,Other Topics,Patterns & OO Design...
# 3

> I am planning on passing the DAO object as a

> parameter to the function. I missed that part.

>

> However, I didn't understand your comment "DAO with

> the parameters already set". Could you please tell me

> what you mean by this comment.

>

> Thanks.

Say you have a DAO class (there are better ways to design DAOs, this is just an example):

class EmployeeDao implements Dao

{

final String employeeId;

DAO(final String employeeId)

{

this.employeeId = employeeId;

}

public ResultSet doRequest()

{

//....

}

}

Then, when you pass this instance to the Paginator, it doesn't need to provide the parameters, it just executes the retrievals per it's design.

dubwaia at 2007-7-13 9:15:59 > top of Java-index,Other Topics,Patterns & OO Design...
# 4

I am working with a DAO class which was poorly designed. The whole freak'n application has one DAO class with a lot of functions. The class has getters to return Objects of multiple data types. That's the reason I resorted to having a class which takes the method name in the dao class and invoke that method using reflection.

Thanks for your info.

Jawahar_m2003a at 2007-7-13 9:15:59 > top of Java-index,Other Topics,Patterns & OO Design...
# 5

> I am working with a DAO class which was poorly

> designed. The whole freak'n application has one DAO

> class with a lot of functions. The class has getters

> to return Objects of multiple data types. That's the

> reason I resorted to having a class which takes the

> method name in the dao class and invoke that method

> using reflection.

>

> Thanks for your info.

You cn still work with this. You can create classes that represent the differenent retrieval types that delegate back to the 'god dao'. Since you recognize the problem with the original design, I would strongly suggest doing this as it will greatly improve your Object model.

dubwaia at 2007-7-13 9:15:59 > top of Java-index,Other Topics,Patterns & OO Design...
# 6
I think I will do as you have suggested. I will create specialized DAO classes and invoke the global DAO from within that class. Thanks for the info.
Jawahar_m2003a at 2007-7-13 9:15:59 > top of Java-index,Other Topics,Patterns & OO Design...
# 7

> I think I will do as you have suggested. I will

> create specialized DAO classes and invoke the global

> DAO from within that class. Thanks for the info.

While you are a it, make sure to create an interface for your

DAO type. You can use this interface to elimate the need for

reflection in your paginator.

dubwaia at 2007-7-13 9:15:59 > top of Java-index,Other Topics,Patterns & OO Design...