|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 7
This is a simple example that demonstrates how the framework can handle business rules reflectively. A more complex example would include the validation of groups of interrelated fields, such as a Credit Card group with card number and expiration date fields. These group validation objects can also fit into the proposed framework by adding additional fields to the property tables.
You can use different mechanisms to load the business rules into the framework. One simple scheme involves the use of a static
class called BusinessRules. This class will load and store all the business rules so that they can be referenced by the application as static variables.
Here's an example:
// initialization of the hashtable
public static Hashtable hRegisterUserRules = new Hashtable();
// a lookup value to enter/find the field names
// - makes the interface cleaner to use.
public static final String sFirstName = "FirstName";
static {
// create a rule object
Rule rule = new Rule();
// set the validation
Rule.setValidation(Rule.TEXT);
// indicate whether or not the field is required
Rule.setMandatory(true);
// add the rule to the hashtable with the fieldname as the key
hRegisterUserRules.put(sFirstName, rule);
}
This is one example of loading the rules from a static class. A more developed framework could load the rules from a properties file or database, thereby providing the development team with a more flexible means to modify the behavior of the application.
Let's assume that the other fields from the RegisterUser action have been entered into the BusinessRules class as shown above. We can now go on to discuss the reusable validation mechanism proposed for this framework. That validation
would be contained in the BusinessObject, which contains a protected method called isValid. This method is responsible for coordinating the loading of the BusinessRules associated with the action being performed and ensuring that the fields passed by the user conform to those rules.
At this point, the development team must choose how it will handle multiple-paged input forms. Should a single action for each page be assumed, or should actions be able to span across pages? In the example I've described here, there is no limitation on the location of fields on one form or another. The data object will catch any missing fields when attempting to write the results to the database. This gives the team developing the business objects complete flexibility in the user interface design.
Having made that design decision, I'll illustrate how you can find the BusinessRules object using reflection. What follows is a simple code fragment that illustrates the reflective loading of a class variable
as an object rather than a set of values.
private Hashtable loadBusinessRules(String sActionRules) throws UnexpectedException
{
// Initialize the rules table to null
Hashtable rulesTable = null;
try {
// Load the BusinessRules Class using the static variable
// containing the fully qualified path value.
Class c = Class.forName( BusinessRules.BUSINESSRULES);
// --- Get the hashtable based upon the action name ---//
// --- (using reflection) --- //
// The loaded class (BusinessRules) has a field such as
// RegisterUserRules that we try to load.
// If the load is successful,
// we call get(null) to load the actual object rather than the value
// We cast the value as a Hashtable and return it to the user.
rulesTable = (Hashtable) c.getField(sActionRules).get(null);
} catch (Exception e) {
// The hashtable was not found. All actions will have some form of
// rule interface.
throw new UnexpectedException(
"No business rules exist for this Action," + sActionRules);
}
return rulesTable;
}
In this case, you're loading the entire Hashtable from the BusinessRules class. This will allow you to use the methods contained within the Hashtable object to perform validation.