|
EJB 最佳实践：数据验证出现在什么地方最合适 |
作者：未知 发布时间：2005-03-12 来源：JSP天空网
|
如何从您的验证代码获得最佳性能
级别：中级
Brett McLaughlin（brett@oreilly.com）
作家兼编辑，O´Reilly and Associates
2003 年 3 月
尽管数据验证是所有企业应用程序的必需组件，但人们对数据验证过程的理解通常很肤浅，并且不能很好地执行。在这篇 EJB 最佳实践专栏文章中，Brett McLaughlin 解释了对基于 EJB 技术的系统进行数据验证的一些幕后概念，并向您展示了如何避免意外的或不可理解的错误消息。
每当您处理应用程序的业务逻辑时，都需要执行验证。应用程序必须有办法确保传入的数据格式正确，并且必须能够执行特定于业务的验证（如针对库存复核采购订单）。
我们将讨论数据验证逻辑应该出现在 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
}
}
对于数据格式验证，您希望使验证逻辑尽可能靠近客户机。数据格式验证经常触发错误页面或要求客户机重新输入格式错误的数据。在这些情况下，您希望花费最少的处理开销迅速向客户机提供反馈。通过将验证逻辑放置在业务委派中，您已经创建了最自然的错误处理方案。当客户机尝试向委派查询带有格式错误的数据时，就会触发错误，请求被直接送回客户机，并就该问题警告用户。
将验证逻辑放置在 bean 实现中会导致低效率的验证过程。错误消息将从 bean 实现传送到委派，而不是直接从委派传送到客户机，这很象 RemoteException，而不象应用程序异常。除了远程异常的代价之外，委派还将付出 JNDI 查找、RMI 流量以及（可能有）额外的业务逻辑的代价 ? 花费在单个验证错误上的力气太多了！
特定于业务的验证
特定于业务的验证完全是一种不同的情形。业务验证错误通常比数据验证错误更复杂，并很少通过客户机交互获得解决。解决特定于业务的错误要求使用额外的实体和会话 bean 以及数据库访问，这些都必须通过 JNDI 和 RMI 事务进行处理。把这种验证放在业务委派上花费的开销会很大。更好的主意是将这种验证移回 EJB 层，尤其是放置到 bean 的实现类中。
在将该验证放置在应用程序的这一层时，所有 RMI 流量都应该是本地的；大多数应用程序服务器都将使用 VM 内的优化，以使 bean-到-bean 交互速度极快。您也可以避免 JNDI 访问，因为许多 bean 已经查找了相关 bean 的主（home）接口。此外，您的业务委派已经处理了所有必要的数据格式验证。
结束语
在决定将验证代码放置在哪里时，很重要的是能够分辨两种验证类型。数据验证是比业务验证简单得多的验证类型，一般的经验是使它尽可能靠近客户机。特定于业务的验证更复杂，并通常需要几种不同的事务来完成。这类验证应该放在 EJB 层，在那里，它可以尽可能地利用现有的进程。
在下一篇技巧文章中，我们将讨论增强应用程序的验证过程的其它方法，并将验证彻底与业务委派隔离开来。在此之前，查看参考资料一节，获取更多阅读资料，我们网上再见！
参考资料
查看 Brett McLaughlin 撰写的完整的 EJB best practices 文章。
“Enterprise JavaBeans fundamentals”教程（developerWorks，2001 年 3 月）是着手了解 EJB 技术的好途径。
Eric Allen 的 Diagnosing Java code 专栏是帮助您管理 Java 代码中常见错误的技巧文章库。
Java 架构设计师 Srikanth Shenoy 在其文章“Best practices in EJB exception handling”（developerWorks，2002 年 5 月）中演示了如何编码以便在基于 EJB 技术的系统上更快地解决问题。
Sun Microsystems 的 EJB 技术主页是了解关于 EJB 技术信息的良好起点。
另一个很棒的参考资料是 TheServerSide.com，它提供了关于 J2EE 的文章和信息。
请参阅 developerWorks Java 技术教程页面，以获取关于 EJB 和 J2EE 技术的 developerWorks 免费教程的列表。
在 developerWorks Java 技术专区可以找到多达数百篇的 Java 技术参考资料。
关于作者
Brett McLaughlin 从 Logo 时代（还记得那个小三角吗？）就开始从事计算机工作了。他现在专门研究用 Java 和 Java 相关技术构建应用程序基础结构。过去几年他一直在 Nextel Communications 和 Allegiance Telecom, Inc. 致力于实现这些基础结构。Brett 是 Java Apache 项目 Turbine 的共同创始人之一，该项目用 Java servlet 为 Web 应用程序开发构建可重用的组件体系结构。他还是 EJBoss 项目（一个开放源码的 EJB 应用程序服务器）和 Cocoon（一个开放源码的 XML Web 发布引擎）的志愿开发人员之一。可通过 brett@oreilly.com 与 Brett 联系。 |
| |
|
|
|
