189 8069 5689
这篇文章主要介绍“EJB中数据验证出现的地方是什么”，在日常操作中，相信很多人在EJB中数据验证出现的地方是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”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中数据验证出现的地方是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！