EJB数据验证呈此刻什么处所最符合

副标题#e#

我们将接头数据验证逻辑应该呈此刻 EJB 应用措施代码的什么位置，而不是专注于验证进程（Java 技能专区的其它处所对此举办了很好的接头）。我们相识了许多构成基于 EJB 技能的应用措施的组件：底层会话 bean 及其业务接口；在实体 bean 及其客户机之间传送数据的值工具以及接受 Web 层和业务层之间的掩护层的各类委派类。验证逻辑十分适合这些组件中的任何一个。实际上，您可以在多个组件中安排验证逻辑，在整个应用措施中分条理地安排它（尽量这样做是不行取的）。因此，我们在此处提出的问题是：在 EJB 应用措施的什么位置安排验证代码最有利？

数据验证的范例

要确定将验证代码安排在什么位置，第一步是相识您正在处理惩罚什么范例的验证。数据名目验证确保所有数据范例（整数、浮点数、字符串等）都是正确的。它还要确认变量都在答允值的范畴之内以及实际的模式按预期的匹配。本质上，数据名目验证处理惩罚验证的任何方面，这些验证不需要应用特定业务法则

特定于业务的验证基于一组业务法则（譬喻，确保所提供的 ISBN 号与您数据库中的实际书籍相匹配）。它险些老是需要对 EJB 层以及应用措施中的其它业务逻辑组件具有会见权。

数据名目验证

确定了正在处理惩罚的验证范例之后，下一步是确定安排代码的位置。在您的 EJB 应用措施中，数据名目验证逻辑可以如下举办安排：

将赋值（setter）要领安排在业务委派上。

将赋值（setter）要领安排在 bean 的长途接口上。

将赋值（setter）要领安排在 bean 的动静工具或值工具上。

对付本示例，我们将假定您正在处理惩罚一个包罗业务委派的 EJB 应用措施。假如是这样，那么您应该采纳某些步调，确保所有的应用措施客户机（处于 Web 层）都在利用委派举办 bean 会见，而不是直接会见 bean。假如确实是这样，那么您可以将所有数据验证代码都安详地安排在业务委派要领中，如清单 1 所示。

清单 1. 业务委派中的数据名目验证 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();
　 }
　 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
}
}

#p#副标题#e#

对付数据名目验证，您但愿使验证逻辑尽大概接近客户机。数据名目验证常常触发错误页面或要求客户机从头输入名目错误的数据。在这些环境下，您但愿耗费最少的处理惩罚开销迅速向客户机提供反馈。通过将验证逻辑安排在业务委派中，您已经建设了最自然的错误处理惩罚方案。当客户机实验向委派查询带有名目错误的数据时，就会触发错误，请求被直接送回客户机，并就该问题告诫用户。

将验证逻辑安排在 bean 实现中会导致低效率的验证进程。错误动静将从 bean 实现传送到委派，而不是直接从委派传送到客户机，这很象 RemoteException，而不象应用措施异常。除了长途异常的价钱之外，委派还将支付 JNDI 查找、RMI 流量以及（大概有）特另外业务逻辑的价钱 — 耗费在单个验证错误上的力气太多了！

特定于业务的验证

#p#分页标题#e#

特定于业务的验证完全是一种差异的景象。业务验证错误凡是比数据验证错误更巨大，并很少通过客户机交互得到办理。办理特定于业务的错误要求利用特另外实体和会话 bean 以及数据库会见，这些都必需通过 JNDI 和 RMI 事务举办处理惩罚。把这种验证放在业务委派上耗费的开销会很大。更好的主意是将这种验证移回 EJB 层，尤其是安排到 bean 的实现类中。

在将该验证安排在应用措施的这一层时，所有 RMI 流量都应该是当地的；大大都应用措施处事器都将利用 VM 内的优化，以使 bean-到-bean 交互速度极快。您也可以制止 JNDI 会见，因为很多 bean 已经查找了相关 bean 的主（home）接口。另外，您的业务委派已经处理惩罚了所有须要的数据名目验证。

竣事语

在抉择将验证代码安排在那边时，很重要的是可以或许判别两种验证范例。数据验证是比业务验证简朴得多的验证范例，一般的履历是使它尽大概接近客户机。特定于业务的验证更巨大，并凡是需要几种差异的事务来完成。这类验证应该放在 EJB 层，在哪里，它可以尽大概地操作现有的历程。