Where EJB data validation is most appropriate

Instead of focusing on the validation process (which is well discussed elsewhere in the Java technology zone), we will discuss where the data validation logic should appear in the EJB application code. We've learned a lot about the components that make up an EJB technology-based application: The underlying session bean and its business interface, the value object that transmits data between the entity bean and its clients, and the various delegation classes that act as a protective layer between the WEB and business tiers. Validation logic is perfect for any one of these components. In fact, you can place validation logic in multiple components, placing it hierarchically throughout the application (although this is undesirable). So the question we ask here is: where is the best place to put validation code in an EJB application?

Types of data validation

The first step in determining where to place the validation code is to understand what type of validation you are dealing with. Data format validation ensures that all data types (integers, floating-point numbers, strings, and so on) are correct. It also confirms that the variables are within the allowable value range and that the actual pattern matches as expected. In essence, data format validation handles any aspect of validation that does not require specific business rules to be applied

Business-specific validation is based on a set of business rules (for example, to ensure that the ISBN number provided matches the actual book in your database). It almost always requires access to the EJB layer and other business logic components in the application.

Data Format Validation

Once you have determined the type of validation that you are working on, the next step is to determine where to place your code. In your EJB application, the data format validation logic can be placed as follows:

Place the assignment (setter) method on the business delegate.

Place the assignment (setter) method on the bean's remote interface.

Place the assignment (setter) method on the Bean's Message object or Value object.

For this example, we will assume that you are working on an EJB application that includes a business delegate. If so, you should take certain steps to ensure that all application clients (in the WEB layer) are using delegation for bean access, rather than directly accessing the bean. If so, you can safely place all data validation code in the business delegation method, as shown in Listing 1.

Listing 1. Data format validation in business delegation package com.ibm.library;

import java.rmi.RemoteException;
import java.util.Iterator;
import java.util.List;
Import Javax.ejb.CreateException;
Import javax.naming.NamingException; 　
public class Librarydelegate implements Ilibrary {
Private ilibrary library;
　 Public Librarydelegate () {
init ();
The
public void init () {
//obtain we session Bean
try {
Libraryhome libraryhome = ( 　　　 Libraryhome) ejbhomefactory.getinstance (). Lookup (
Java:comp/env/ejb/libraryhome, libraryhome.class);
Library = Libraryhome.create (); 　
} catch (Namingexception e) {
throw new RuntimeException (e);
　 catch (CreateException e) {
throw new RuntimeException (e);
　 catch (RemoteException e) {
throw new RuntimeException (e);

}
//No validation required for accessor (getter) methods
Public Boolean Checkout (book book) throws Applicat ionexception {
//No validation required here; the OBJECT type
//takes care of it
try {
return library.checkout (book)
　 catch (RemoteException e) {
throw new ApplicationException (e);

}
Public boolean Checkout (List books) throws ApplicationException {
//Validate List
for (iterator I = Books.iterator (); I.hasnext (); {
Object obj = I.next ();
if! (obj instanceof book) {
throw new ApplicationException (
Applicationexception.validation_error, "only books are allowed in" Put list "); 　
}
}
try {
return library.checkout (books);
　 catch (RemoteException e) {
throw new ApplicationException (e);
}
}
//And so on ...
public void Destroy () {
//In the this case, doing nothing
}
}