Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what is the place where data verification appears in EJB". In daily operation, I believe that many people have doubts about where data verification appears in EJB. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubt of "what is the place where data verification appears in EJB?" Next, please follow the editor to study!

We will discuss where the data validation logic should appear in the EJB application code, rather than focusing on the validation process (which is well discussed elsewhere in the Java technology zone). In previous tips in this series, we learned about many of the components that make up an EJB-based application: the underlying session bean and its business interface; the value objects that pass data between the entity bean and its clients, and the various delegation classes that act as the protection layer between the web layer and the business layer. The validation logic is well suited to any of these components. In fact, you can place validation logic in multiple components and hierarchically throughout the application (although this is not desirable). Therefore, the question we ask here is: where is it most advantageous to place validation code in an EJB application?

Types of data validation

To determine where to place the validation code, the first step is to know 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 range of allowable values and that the actual patterns match as expected. In essence, data format validation deals with any aspect of validation, which does not require the application of specific business rules

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

Data format verification

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

Place the setter method on the business delegate.

Place the setter method on the remote interface of bean.

Place the setter method on the message object or value object of the bean.

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

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

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 ()

}

Public void init () {

/ / Look up and obtain our 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 ApplicationException {

/ / 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 the input list")

}

}

Try {

Return library.checkout (books)

} catch (RemoteException e) {

Throw new ApplicationException (e)

}

}

/ / And so on...

Public void destroy () {

/ / In this case, do nothing

}

}

For data format validation, you want the validation logic to be as close to the client as possible. Data format validation often triggers error pages or requires clients to re-enter malformed data. In these cases, you want to provide feedback to the client quickly with minimal processing overhead. By placing the validation logic in the business delegate, you have created the most natural error handling scenario. When the client tries to query the delegate for malformed data, an error is triggered, the request is sent directly back to the client, and the user is warned about the problem.

Placing validation logic in the bean implementation results in an inefficient validation process. Error messages are passed from the bean implementation to the delegate rather than directly from the delegate to the client, much like RemoteException rather than application exceptions. In addition to the cost of remote exceptions, delegates also pay the price of JNDI lookups, RMI traffic, and (possibly) additional business logic-too much effort is spent on a single validation error!

Business-specific authentication

Business-specific validation is a completely different scenario. Business validation errors are usually more complex than data validation errors and are rarely resolved through client-client interaction. Resolving business-specific errors requires the use of additional entity and session bean and database access, which must be handled through JNDI and RMI transactions. Putting this kind of validation on business delegates can be costly. A better idea is to move this validation back to the EJB layer, especially in the implementation class of bean.

When this authentication is placed at this layer of the application, all RMI traffic should be local; most application servers will use optimizations within VM to make bean--to-bean interactions extremely fast. You can also avoid JNDI access because many bean have looked up the home interface of the relevant bean. In addition, your business delegate has handled all the necessary data format validation.

At this point, the study of "what is the place of data validation in EJB" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.