|
|
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 2 of 7
Once the action type is identified, the business object can be instantiated. The proxy servlet can initialize the business object as follows:
try{
businessObject.init( ... );
} catch (ExampleException e){
exceptionHandler.handleException( e);
}
In Part 1 of this series, I demonstrated that you could create these business objects by searching for classes related to the action name that is attached to the page using reflection. Let's assume I've already created a business object for this example.
The BusinessObject interface defines an init method. This method takes a Hashtable of the input parameters passed to the servlet. Using this Hashtable, the business object can retrieve the data from the servlet without relying on the HttpServletRequest object, thereby reducing the dependency on the deployment platform.
You can develop a hierarchy of business objects to create greater functionality with less code. Because the proxy servlet
uses the Class object's forName method to find the business object, no logic is needed to keep track of which business object to load. In other words, you
don't need to write code that analyzes the action name and determines whether or not that name is associated to a form or
a page.
So, you can invoke the RegisterUser business logic through the action RegisterUser. Your application need not understand that this was achieved through a link -- it is performed implicitly through reflection.
In fact, a one-to-one correlation between business logic and action is not necessary, depending on the required business rules.
My example application will process user input through a form and display report output to the user. I've developed some simple objects to present this simple framework. Their names and behaviors are shown below:
DefaultBusinessObject:
ReportBusinessObjectextends DefaultBusinessObject
For now, I'll assume that BusinessServices has loaded the proper object. I'll elaborate on how to load these objects when I develop the exception handling below. For
now, the key is to understand BusinessRules and how you can use them to achieve a high degree of functionality without a lot of coding.
I'll use a registration page to illustrate the benefits of using this framework to handle business rules. Let's assume that the registration page has six fields with the following properties:
| Field Name | Field Type | Mandatory? |
|---|---|---|
| First Name | Text | Yes |
| Last Name | Text | No |
| Email Address | Yes | |
| City | Text | Yes |
| State | State | No |
| Country | Text | Yes |
You can write a business object that validates the fields on the page and ensures that they satisfy the business rules associated with the registration action. In this case, three different objects can handle the validation: the email validator, the text validator, and the state validator. These three validation objects are linked into the framework using reflection. The business object will reflectively load each validator as called for in the property table above. This will ensure that the fields are validated properly without requiring the business object developer to hardcode the fields present on a given form page. The power of this reflective approach lies in the fact that a single business object can perform the validation for many, if not all, of the pages in the application. This reduces the development and testing time because the validation code is effectively isolated from the application.