EJB最佳实践:数据验证出现在什么地方最合适 - 编程入门网
}
// 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
}
}
EJB最佳实践:数据验证出现在什么地方最合适(2)时间:2011-01-20 IBM Brett McLaughlin对于数据格式验证，您希望使验证逻辑尽可能靠近客户机。数据格式验证经常触发错误页面或要求客户机重新输入格式错误的数据。在这些情况下，您希望花费最少的处理开销迅速向客户机提供反馈。通过将验证逻辑放置在业务委派中，您已经创建了最自然的错误处理方案。当客户机尝试向委派查询带有格式错误的数据时，就会触发错误，请求被直接送回客户机，并就该问题警告用户。 将验证逻辑放置在 bean 实现中会导致低效率的验证过程。错误消息将从 bean 实现传送到委派，而不是直接从委派传送到客户机，这很象 RemoteException ，而不象应用程序异常。除了远程异常的代价之外，委派还将付出 JNDI 查找、RMI 流量以及（可能有）额外的业务逻辑的代价 — 花费在单个验证错误上的力气太多了！ 特定于业务的验证 特定于业务的验证完全是一种不同的情形。业务验证错误通常比数据验证错误更复杂，并很少通过客户机交互获得解决。解决特定于业务的错误要求使用额外的实体和会话 bean 以及数据库访问，这些都必须通过 JNDI 和 RMI 事务进行处理。把这种验证放在业务委派上花费的开销会很大。更好的主意是将这种验证移回 EJB 层，尤其是放置到 bean 的实现类中。 在将该验证放置在应用程序的这一层时，所有 RMI 流量都应该是本地的；大多数应用程序服务器都将使用 VM 内的优化，以使 bean-到-bean 交互速度极快。您也可以避免 JNDI 访问，因为许多 bean 已经查找了相关 bean 的主（home）接口。此外，您的业务委派已经处理了所有必要的数据格式验证。 结束语 在决定将验证代码放置在哪里时，很重要的是能够分辨两种验证类型。数据验证是比业务验证简单得多的验证类型，一般的经验是使它尽可能靠近客户机。特定于业务的验证更复杂，并通常需要几种不同的事务来完成。这类验证应该放在 EJB 层，在那里，它可以尽可能地利用现有的进程。 在下一篇技巧文章中，我们将讨论增强应用程序的验证过程的其它方法，并将验证彻底与业务委派隔离开来。在此之前，查看 参考资料一节，获取更多阅读资料，我们网上再见！ |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
