Design problem

Cosmin posted on Tuesday, January 22, 2008

Hi,

I got into a design problem recently. We developed in house a purchasing system. Among other entities we have a purchase order and a corresponding info class for read only display purposes.
The POInfo(and corresponding collection class) class is used mainly to populate the search result grid when users are searching for POs. When we search we use a stored procedure which joins severeal foreign key tables to gather all the information required.
Everything was fine until a new requirement came from the business people, especially managers who are part of the PO approval chain. They want to see all the POs they approved/rejected. For this new requirement we need to join several different tables in the stored procedure.
What is the right way to implemet it? Should we create a different Info Class for this case, which in the portal_fetch we call a new stored procedure similar to the POInfo but with additional joins?
We thought adding this new class but then when you add something new, a field for example, you have to go modify all specific Info classes and before we proceed I just want to see how you might implement it.

This may sound pretty simple but I want to hear other's opinions and suggestions.

Thanks,
Cosmin

SomeGuy replied on Tuesday, January 22, 2008

If the data returned is the same, I usually just add an additional factory method specific to the use case. ie. GetPurchaseOrderByManager(), and internally I implement a seperate Criteria class (ManagerCriteria) and different Fetch. Most of the time, you can implement it like the Insert/Update methods where you have different FetchByXXX methods that create the Command object and setup the initial parameters, and then call a common doFetch().

E