|
In the book, Enterprise JavaBeans (O'Reilly), dependent objects are offered as design option for pass-by-value objects. A dependent object is a business object that realizes a fairly simple concept like address or phone number. A dependent object is dependent on the entity that owns it to give it meaning; its an attribute of an entity not and not a bean. Because dependent objects are limited in scope and very fine grained, they are good candidates for pass-by-value. You can find many successfully finished projects at the main page of our nursing paper writing service at https://place-4-papers.com/nursing-essay-writing-service/.
Dependent objects have another advantage: They make excellent homes for format validation rules. Format validation ensures that a simple data construct adheres to a predetermined structure or form. As an example, a zip code has a certain form it must follow: It must be composed of digits; it must be 5 or 9 digits in length; and it must use a hyphen as a separator. Checking to see that a zip code follows these rules is format validation.
One problem that all developers face with validation is deciding where to put it. Should data be validated at the user interface (UI), or should it be done by the bean that uses the data. Validating the data at the UI has the advantage of conserving network resources and improving performance. Validating data in the bean, on the middle tier, ensures that the logic is reusable across user interfaces. Dependent objects provide a logical compromise that allows data to be validated on the client, but remain UI independent. By placing the validation logic in the constructor of a dependent object, data is automatically validated when it's created. When data is entered at the UI (GUI, Servlet, JSP, or whatever) it can be validated on the UI using its corresponding dependent object. If its valid the dependent object is created with no exceptions.
As an example, a ZipCode dependent object has been created which adheres to the rules for a dependent object as defined in the book, but also includes format validation rules in the constructor.
| Format Validation in the ZipCode class |
|
public class ZipCode implements java.io.Serializable {
public String code;
public String boxNumber;
public ZipCode(String zipcode) throws Exception{
if(zipcode == null)
throw new ValidationException("Zip code can not be null");
else if(zipcode.length()==5 && ! isDigits(zipcode))
throw new ValidationException("Zip code must be all digits");
else if(zipcode.length()==10 )
if(zipcode.charAt(5) == '-' ) {
code = zipcode.substring(0,5);
if(isDigits( code )){
boxNumber = zipcode.substring(6);
if(isDigits( boxNumber ))
return;
}
}
throw new Exception("Zip code must be of the form #####-####");
}
public boolean isDigits(String str){
for(int i = 0; i < str.length(); i++){
char chr = str.charAt(i);
if( ! Character.isDigit(chr)){
return false;
}
}
return true;
}
public String getCode( ) { return code; }
public String getBoxNumber( ) { return boxNumber; }
public String toString( ){
return code+'-'+boxNumber;
}
}
|
|
Of course this is a fairly simple example, but it illustrates that format validation is effectively done in dependent objects when the object is constructed at the user interface or client. Any format validation errors are immediately reported. In addition, any business object that uses ZipCode automatically gains the benefit of the validation code it contains making the validation rules reusable across beans. Placing format validation in the dependent object is also a good coding practice because it makes the dependent object responsible for its own validation -- responsibility is a key concept in OO programming.
As an alternative, format validation can be moved to the accessors of enterprise beans. If, for example, a customer bean has accessors for setting and obtaining the zip code, as shown below, the validation code would reside in the accessors. While this is more efficient from a network perspective -- passing a String value appears more efficient then passing a dependent object by value -- its less reusable and encapsulated than housing format validation rules in dependent objects.
Of course, dependent objects are only useful if the Enterprise JavaBeans implementation supports pass-by-value. Several of the CORBA systems do not, supporting a cruder format of pass-by-value where CORBA structures are used.
|
