2005年11月10日

其实,就算用Java建造一个不是很烦琐的web应用,也不是件轻松的事情。 在构架的一开始就有很多事情要考虑。 从高处看,摆在开发者面前有很多问题:要考虑是怎样建立用户接口?在哪里处理业务逻辑? 怎样持久化的数据。 而这三层构架中,每一层都有他们要仔细考虑的。 各个层该使用什么技术? 怎样的设计能松散耦合还能灵活改变? 怎样替换某个层而不影响整体构架?应用程序如何做各种级别的业务处理(比如事务处理)?

构架一个Web应用需要弄明白好多问题。 幸运的是,已经有不少开发者已经遇到过这类问题,并且建立了处理这类问题的框架。 一个好框架具备以下几点: 减轻开发者处理复杂的问题的负担(“不重复发明轮子”); 内部有良好的扩展; 并且有一个支持它的强大的用户团体。 好的构架一般有针对性的处理某一类问题,并且能将它做好(Do One Thing well)。 然而,你的程序中有几个层可能需要使用特定的框架,已经完成的UI(用户接口) 并不代表你也可以把你的业务逻辑和持久逻辑偶合到你的UI部分。 举个例子, 你不该在一个Controller(控制器)里面写JDBC代码作为你的业务逻辑, 这不是控制器应该提供的。 一个UI 控制器应该委派给其它给在UI范围之外的轻量级组件。 好的框架应该能指导代码如何分布。 更重要的是,框架能把开发者从编码中解放出来,使他们能专心于应用程序的逻辑(这对客户来说很重要)。

这篇文章将讨论怎样结合几种著名的框架来使得你的应用程序做到松弛耦合。

如何建立你的架构,并且怎样让你的各个应用层保持一致。?如何整合框架以便让每个层在以一种松散偶合的方式彼此作用而不用管低层的技术细节?这对我们来说真是一种挑战。 这里讨论一个整合框架的策略( 使用3 种受欢迎的开源框架) :表示层我们用Struts; 业务层我们用Spring;而持久层则用Hibernate。 你也可以用其他FrameWork替换只要能得到同样的效果。 见图1 (框架组合示意图)


应用程序的分层

大部分的Web应用在职责上至少能被分成4层。 这四层是:presentation(描述),persistence(持久),business(业务)和domain model(域模块)。每个层在处理程序上都应该有一项明确的责任, 而不应该在功能上与其它层混合,并且每个层要与其它层分开的,但要给他们之间放一个通信接口。 我们就从介绍各个层开始,讨论一下这些层应该提供什么,不应该提供什么。

表示层(The Presentation Layer)

一般来讲,一个典型的Web应用的的末端应该是表示层。 很多Java发者也理解Struts所提供的。 象业务逻辑之类的被打包到org.apache.struts.Action., 因此,我们很赞成使用Struts这样的框架。

下面是Struts所负责的:

* 管理用户的请求,做出相应的响应。
* 提供一个Controller ,委派调用业务逻辑和其它上层处理。
* 处理异常,抛给Struts Action
* 为显示提供一个模型
* UI验证。

以下条款,不该在Struts显示层的编码中经常出现。 它们与显示层无关的。

* 直接的与数据库通信,例如JDBC调用。
* 与你应用程序相关联的业务逻辑以及校验。
* 事物管理。

在表示层引入这些代码,则会带来高偶合和麻烦的维护。

持久层(The Persistence Layer)

典型的Web应用的另一个末端是持久层。这里通常是程序最容易失控的地方。开发者总是低估构建他们自己的持久框架的挑战性。系统内部的持续层不但需要大量调试时间,而且还经常缺少功能使之变得难以控制,这是持久层的通病。 还好有几个ORM开源框架很好的解决了这类问题。尤其是Hibernate。 Hibernate为java提供了OR持久化机制和查询服务, 它还给已经熟悉SQL和JDBC API 的Java开发者一个学习桥梁,他们学习起来很方便。 Hibernate的持久对象是基于POJO和Java collections。此外,使用Hibernate并不妨碍你正在使用的IDE。

请看下面的条目,你在持久层编码中需要了解的。

* 查询对象的相关信息的语句。 Hibernate通过一个OO查询语言(HQL)或者正则表达的API来完成查询。 HQL非常类似于SQL– 只是把SQL里的table和columns用Object和它的fields代替。 你需要学习一些新的HQL语言; 不管怎样,他们容易理解而文档也做的很好。 HQL是一种对象查询的自然语言,花很小的代价就能学习它。
* 如何存储,更新,删除数据库记录。
* 象Hibernate这类的高级ORM框架支持大部分主流数据库,并且他们支持 Parent/child关系,事物处理,继承和多态。

业务层(The Business Layer)

一个典型Web应用的中间部分是业务层或者服务层。 从编码的视角来看,这层是最容易被忽视的一层。 而我们却往往在UI层或持久层周围看到这些业务处理的代码,这其实是不正确的,因为它导致了程序代码的紧密偶合,这样一来,随着时间推移这些代码很难维护。幸好,针对这一问题有好几种Frameworks存在。 最受欢迎的两个框架是Spring和PicoContainer。 这些为也被称为microcontainers,他们能让你很好的把对象搭配起来。 这两个框架都着手于‘依赖注射’(dependency injection)(还有我们知道的‘控制反转’Inversion of Control=IoC)这样的简单概念。 这篇文章将关注于Spring的注射(译注:通过一个给定参数的Setter方法来构造Bean,有所不同于Factory), Spring还提供了Setter Injection(type2),Constructor Injection(type3)等方式供我们选择。 Spring把程序中所涉及到包含业务逻辑和Dao的Objects——例如transaction management handler(事物管理控制)、Object Factoris(对象工厂)、service objects(服务组件)——都通过XML来配置联系起来。

后面我们会举个例子来揭示一下Spring 是怎样运用这些概念。

业务层所负责的如下:

* 处理应用程序的 业务逻辑和业务校验
* 管理事物
* 允许与其它层相互作用的接口
* 管理业务层级别的对象的依赖。
* 在显示层和持久层之间增加了一个灵活的机制,使得他们不直接的联系在一起。
* 通过揭示 从显示层到业务层之间的Context来得到business services。
* 管理程序的执行(从业务层到持久层)。

域模块层(The Domain Model Layer )

既然我们致力于的是一个不是很复杂的Web的应用, 我们需要一个对象集合,让它在不同层之间移动的。 域模块层由实际需求中的业务对象组成 比如, OrderLineItem , Product等等。 开发者在这层 不用管那些DTOs,仅关注domain object即可。 例如,Hibernate允许你将数据库中的信息存放入对象(domain objects),这样你可以在连接断开的情况下把这些数据显示到UI层。 而那些对象也可以返回给持续层,从而在数据库里更新。 而且,你不必把对象转化成DTOs(这可能似的它在不同层之间的在传输过程中丢失),这个模型使得Java开发者能很自然运用OO,而不需要附加的编码。

一个简单例子

既然我们已经从全局上理解这些组件。 现在就让我们开始实践吧。 我们还是用 Struts,Spring 和Hibernate。这三个框架已经被描述够多了,这里就不重复介绍了。 这篇文章举例指导你如何使用这三个框架整合开发, 并向你揭示 一个请求是如何贯穿于各个层的。(从用户的加入一个Order到数据库,显示;进而更新、删除)。

从这里可以下载到程序程序原代码(download)

既然每个层是互相作用的,我们就先来创建domain objects。首先,我们要在这些Object中要确定那些是需要持久化的,哪些是提供给business logic,那些是显示接口的设计。 下一步,我们将配置我们的持久层并且定义好Hibernate的OR mappings。然后定义好Business Objects。有了这些组成部分之后,我们将 使用Spring把这些连接起来。 最后,我们提供给Spring一个持久层,从这个持久层里我们可以知道它是如何与业务逻辑层(business service layer)通信的,以及它是怎样处理其他层抛出的异常的。。

域对象层(Domain Object Layer)

这层是编码的着手点,我们的编码就从这层开始。 例子中Order 与OrderItem 是一个One—To—Many的关系。 下面就是Domain Object Layer的两个对象:

· com.meagle.bo.Order.java: 包含了一个Order的概要信息
· com.meagle.bo.OrderLineItem.java: 包含了Order的详细信息

好好考虑怎你的package命名,这反应出了你是怎样分层的。 例如 domain objects在程序中可能打包在com.meagle.bo内。 更详细一点将打包在com. meagle.bo的子目录下面。business logic应该从com.meagle.serice开始打包,而DAO 对象应该位于com.meagle.service.dao.hibernate。反应Forms和Actions的 持久对象(presentation classes) 应该分别放在 com.meagle.action和com.meagle.forms包。 准确的给包命名使得你的classes很好分割并且易于维护,并且在你添加新的classes时,能使得程序结构上保持上下一致。

持久层的配置(Persistence Layer Configuration)
建立Hibernate的持久层 需要好几个步骤。 第一步让我们把BO持久化。 既然Hibernate是通过POJO工作的, 因此Order和 OrderLineItem对象需要给所有的fileds 加上getter,setter方法。 Hibernate通过XML文件来映射(OR)对象,以下两个xml文件分别映射了Order 和OrderItem对象。(这里有个叫XDoclet工具可以自动生成你的XML影射文件)

Order.hbm.xml
OrderLineItem.hbm.xml

你可以在WebContent/WEB-INF/classes/com/meagle/bo目录下找到这些xml文件。Hibernate的 SessionFactory 是用来告诉程序 应该与哪个数据库通信,该使用哪个连接池或使用了DataSource, 应该加载哪些持久对象。而Session接口是用来完成Selecting,Saving,Delete和Updating这些操作。 后面的我们将讲述SessionFactory和Session是怎样设置的。

业务层的配置(Business Layer Configuration)

既然我们已经有了domain objects,接下来我们就要business service objects了,用他们来执行程序的logic,调用持久层,得到UI层的requests,处理transactions,并且控制exceptions。 为了将这些连接起来并且易于管理,我们将使用面向方面的 SpringFramework。 Spring 提供了 控制倒置(inversion of control 0==IoC)和注射依赖设置(setter dependency injection)这些方式(可供选择),用XML文件将对象连接起来。 IoC是一个简单概念(它允许一个对象在上层接受其他对象的创建),用IoC这种方式让你的对象从创建中释放了出来,降低了偶合度。

这里是一个没有使用IoC的对象创建的例子,它有很高偶合度。

图 2.没有使用 IoC. A 创建了 B 和 C

而这里是一个使用IoC的例子,这种方式允许对象在高层可以创建并进入另外一个对象,所以这样可以直接被执行。

图 3. 对象使用了 IoC。 A 包含了接受B,C的 setter方法 , 这同样达到了 由A创建B,C的目的。

建立我们的业务服务对象(Building Our Business Service Objects)

Business Object中的Setter方法接受的是接口,这样我们可以很松散的定义对象实现,然后注入。 在我们的案例中,我们将用一个business service object接收一个DAO,用它来控制domain objects的持久化。 由于在这个例子中使用了Hibernate,我们可以很方便的用其他持久框架实现 同时通知Spring 有新的DAO可以使用了。

在面向接口的编程中,你会明白 “注射依赖”模式是怎样松散耦合你的业务逻辑和持久机制的:)。

下面是一个接口business service object,DAO代码片段:


public interface IOrderService {
public abstract Order saveNewOrder(Order order)
throws OrderException, OrderMinimumAmountException;

public abstract List findOrderByUser( String user) throws OrderException;

public abstract Order findOrderById(int id) throws OrderException;

public abstract void setOrderDAO( IOrderDAO orderDAO);
}


注意到这段代码里有一个 setOrderDao(),它就是一个DAO Object设置方法(注射器)。 但这里并没有一个getOrderDao的方法,这不必要,因为你并不会在外部访问这个orderDao。这个DAO Objecte将被调用,和我们的persistence layer 通信。我们将用Spring把DAO Object 和 business service object搭配起来的。因为我们是面向接口编程的,所以并不需要将实现类紧密的耦合在一起。

接下去我们开始我们的DAO的实现类进行编码。 既然Spring已经有对Hibernate的支持,那这个例子就直接继承HibernateDaoSupport类了,这个类很有用,我们可以参考HibernateTemplate(它主要是针对HibernateDaoSupport的一个用法,译注:具体可以查看Srping 的API)。 下面是这个DAO接口代码:


public interface IOrderDAO {
public abstract Order findOrderById(
final int id);

public abstract List findOrdersPlaceByUser(
final String placedBy);
public abstract Order saveOrder(
final Order order);
}


我们仍然要给我们持久层组装很多关联的对象,这里包含了HibernateSessionFactory 和TransactionManager。 Spring 提供了一个 HibernateTransactionManager,他用线程捆绑了一个Hibernate Session,用它来支持transactions(请查看ThreadLocal) 。

下面是HibernateSessionFactory 和 HibernateTransactionManager:的配置:


<bean id="mySessionFactory"
class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
<property name="mappingResources">
<list>
<value>
com/meagle/bo/Order.hbm.xml
</value>
<value>
com/meagle/bo/OrderLineItem.hbm.xml
</value>
</list>
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">
net.sf.hibernate.dialect.MySQLDialect
</prop>
<prop key="hibernate.show_sql">
false
</prop>
<prop key="hibernate.proxool.xml">
C:/MyWebApps/.../WEB-INF/proxool.xml
</prop>
<prop key="hibernate.proxool.pool_alias">
spring
</prop>
</props>
</property>
</bean>

<!-- Transaction manager for a single Hibernate
SessionFactory (alternative to JTA) -->
<bean id="myTransactionManager"
class="org.springframework.orm.hibernate.HibernateTransactionManager">
<property name="sessionFactory">
<ref local="mySessionFactory"/>
</property>
</bean>


可以看出:每个对象都可以在Spring 配置信息中用<bean>标签引用。在这里,mySessionFactory引用了HibernateSessionFactory,而myTransactionManager引用了HibernateTransactionManage。 注意代码中myTransactionManger Bean有个sessionFactory属性。 HibernateTransactionManager有个sessionFactory setter 和 getter方法,这是用来在Spring启动的时候实现“依赖注入” (dependency injection)的。 在sessionFactory 属性里 引用mySessionFactory。这两个对象在Spring容器初始化后就被组装了起来了。 这样的搭配让你从 单例(singleton objects)和工厂(factories)中解放了出来,降低了代码的维护代价。 mySessionFactory.的两个属性,分别是用来注入mappingResources 和 hibernatePropertes的。通常,如果你在Spring之外使用Hibernate,这样的设置应该放在hibernate.cfg.xml中的。 不管怎样,Spring提供了一个便捷的方式—–在Spring内部配置中并入了Hibernate的配置。 如果要得到更多的信息,可以查阅Spring API。

既然我们已经组装配置好了Service Beans,就需要把Business Service Object和 DAO也组装起来,并把这些对象配到一个事务管理器(transaction manager)里。

在Spring中的配置信息:


<!-- ORDER SERVICE -->
<bean id="orderService"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager">
<ref local="myTransactionManager"/>
</property>
<property name="target">
<ref local="orderTarget"/>
</property>
<property name="transactionAttributes">
<props>
<prop key="find*">
PROPAGATION_REQUIRED,readOnly,-OrderException
</prop>
<prop key="save*">
PROPAGATION_REQUIRED,-OrderException
</prop>
</props>
</property>
</bean>

<!-- ORDER TARGET PRIMARY BUSINESS OBJECT:
Hibernate implementation -->
<bean id="orderTarget"
class="com.meagle.service.spring.OrderServiceSpringImpl">
<property name="orderDAO">
<ref local="orderDAO"/>
</property>
</bean>

<!-- ORDER DAO OBJECT -->
<bean id="orderDAO"
class="com.meagle.service.dao.hibernate.OrderHibernateDAO">
<property name="sessionFactory">
<ref local="mySessionFactory"/>
</property>
</bean>


图4 是我们对象搭建的一个提纲。 从中可以看出,每个对象都联系着Spring,并且能通过Spring注入到其他对象。把它与Spring的配置文件比较,观察他们之间的关系

图 4. Spring就是这样基于配置文件,将各个Bean搭建在一起。

这个例子使用一个TransactionProxyFactoryBean,它定义了一个setTransactionManager()。 这对象很有用,他能很方便的处理你申明的事物还有Service Object。 你可以通过transactionAttributes属性来定义怎样处理。 想知道更多还是参考TransactionAttributeEditor吧。

TransactionProxyFactoryBean 还有个setter. 这会被我们 Business service object(orderTarget)引用, orderTarget定义了 业务服务层,并且它还有个属性,由setOrderDAO()引用。这个属性

Spring 和Bean 的还有一点要注意的: bean可以以用两种方式创造。 这些都在单例模式(Sington)和原型模式(propotype)中定义了。 默认的方式是singleton,这意味着共享的实例将被束缚。 而原形模式是在Spring用到bean的时候允许新建实例的。当每个用户需要得到他们自己Bean的Copy时,你应该仅使用prototype模式。(更多的请参考设计模式中的单例模式和原形模式)

提供一个服务定位器(Providing a Service Locator)

既然我们已经将我们的Serices和DAO搭配起来了。我们需要把我们的Service显示到其他层。 这个通常是在Struts或者Swing这层里编码。一个简单方法就是用 服务定位器返回给Spring context 。当然,可以通过直接调用Spring中的Bean来做。

下面是一个Struts Actin 中的服务定位器的一个例子。

 
public abstract class BaseAction extends Action {

private IOrderService orderService;

public void setServlet(ActionServlet
actionServlet) {
super.setServlet(actionServlet);
ServletContext servletContext =
actionServlet.getServletContext();

WebApplicationContext wac =
WebApplicationContextUtils.
getRequiredWebApplicationContext(
servletContext);

this.orderService = (IOrderService)
wac.getBean("orderService");
}

protected IOrderService getOrderService() {
return orderService;
}
}


UI 层配置 (UI Layer Configuration)
这个例子里UI层 使用了Struts framework. 这里我们要讲述一下在给程序分层的时候, 哪些是和Struts部分的。我们就从一个Struts-config.xml文件中的Action的配置信息开始吧。

struts-config.xml file.


<action path="/SaveNewOrder"
type="com.meagle.action.SaveOrderAction"
name="OrderForm"
scope="request"
validate="true"
input="/NewOrder.jsp">
<display-name>Save New Order</display-name>
<exception key="error.order.save"
path="/NewOrder.jsp"
scope="request"
type="com.meagle.exception.OrderException"/>
<exception key="error.order.not.enough.money"
path="/NewOrder.jsp"
scope="request"
type="com.meagle.exception.OrderMinimumAmountException"/>
<forward name="success" path="/ViewOrder.jsp"/>
<forward name="failure" path="/NewOrder.jsp"/>
</action>


SaveNewOrder 这个Action是用来持久化UI层里的表单提交过来Order的。这是Struts中一个很典型的Action; 注意观察这个Action中exception配置,这些Exceptions也在Spring 配置文件(applicationContext-hibernate.xml)中配置了(就在 business service object 的transactionAttributes属性里)。 当异常在业务层被被抛出时,我们可以控制他们,并适当的显示给UI层。

第一个异常,OrderException,在持久层保存order对象失败的时候被触发。这将导致事物回滚并且通过BO把异常回传到Struts这一层。

第二个异常,OrderMinimumAmountException也同第一个一样。

搭配整和的最后一步 通过是让你显示层和业务层相结合。这个已经被服务定位器(service locator)实现了(前面讨论过了), 这里服务层作为一个接口提供给我们的业务逻辑和持久层。

SaveNewOrder Action 在Struts中用一个服务定位器(service locator)来调用执行业务方法的。 方法代码如下:


public ActionForward execute(
ActionMapping mapping,
ActionForm form,
javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
throws java.lang.Exception {
OrderForm oForm = (OrderForm) form;

// Use the form to build an Order object that
// can be saved in the persistence layer.
// See the full source code in the sample app.

// Obtain the wired business service object
// from the service locator configuration
// in BaseAction.
// Delegate the save to the service layer and
// further upstream to save the Order object.

getOrderService().saveNewOrder(order);
oForm.setOrder(order);
ActionMessages messages = new ActionMessages();
messages.add(
ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(
"message.order.saved.successfully"));

saveMessages(request, messages);
return mapping.findForward("success");
}


总结

这篇文章在技术和构架方面掩盖了很多低层的基础信息, 文章的主要的意图在于让你意识到如何给你应用程序分层。 分层可以“解耦”你的代码——允许新的组件被添加进来,而且让你的代码易于维护。 这里用到的技术只是专注于把“解偶”做好。 不管怎样,使用这样的构架可以让你用其他技术代替现在的层。 例如,你可能不使用Hibernate实现持久化。既然你在DAO中面向接口的编程的,所以你完全可以用iBATIS来代替。或者,你也可能想用Struts外的其他的技术或者框架替换现在的UI层(转换久层,实现层并不应该直接影响到你的业务逻辑和业务服务层)。 用适当的框架搭建你的Web应用,其实也不是一件烦琐的工作,更主要的是它“解耦”了你程序中的各个层。

后记

看完这篇文章后,只是觉得很喜欢,于是就翻译了,当然同时也准备着挨大家扔来的鸡蛋:)。

这篇文章里并没有太多的技术细节,和详细的步骤。如果你从未使用过这些框架而在运行实例程序遇上困难的话,可以到CSDN论坛Java Open Source版发贴,我一定会详细解答的(啊哦,这不算做广告吧?),

文章是从一个构架的角度讲述了如何搭配现有的开源框架进行分层, 有太多的术语我都不知道怎么表达,而且可能有很多语句存在错误。如果影响了你的阅读,请你直接点原文地址,我同时也象你说声抱歉。

作者简介:Mark Eagle 高级软件工程师,亚特兰大。
翻 译:Totodo(zhangli@telecomjs.com) 软件工程师

参考:
Struts:http://jakarta.apache.org/struts/index.html
Spring: http://www.springframework.org/
Hibernate: http://www.hibernate.org/
http://www.hibernate.org.cn/
关于控制反转IOC和依赖注射:http://www.martinfowler.com/articles/injection.html

  虽然许多文章曾经讨论过J2EE最佳实践。那么,为什么我还要再写一篇文章呢?本文究竟与以前的文章有何不同或者说比其他文章好在哪呢?
  首先,本文的目标读者是正在从事技术工作的架构师。为了避免浪费大家的才智,我会避免讲述一些陈腐的最佳实践,例如"日常构建(build daily)"、"测试一切(test everything)"和"经常集成( integrate often)。 任何具有称职架构师的项目都有分工明确的、定义良好的团队结构。他们还为进行编码检查、构建代码(每日或在需要时)、进行测试(单元、集成和系统的)、部署和配置/释放管理而具备已记录的过程。
  其次,我将跳过通常吹捧的最佳实践,例如"基于接口的设计"、"使用著名的设计模型"以及"使用面向服务的架构"等。相反,我将集中讲述我曾学过并且使用了若干年的6(不是很多)个方面的in-the-trench课程。最后,本文的目的是让您思考一下自己的架构,提供工作代码示例或者解决方案超出了本文的范围。下面就让我介绍一下这6课:


第1课:切勿绕过服务器端验证
  作为一位软件顾问,我曾有机会不但设计并实现了Web应用程序,而且还评估/审核了许多Web应用程序。在复杂的、并且用JavaScript客户端封装的应用程序内,我经常遇到对用户输入信息执行大量检查的Web页面。即使HTML元素具有数据有效性的属性也如此,例如MAXLENGTH。只有在成功验证所有输入信息后,才能提交HTML表单。结果,一旦服务器端收到通知表单(请求),便恰当地执行业务逻辑。
  在此,您发现问题了么?开发人员已经做了许多重要的假设。例如,他们假设所有的Web应用程序用户都同样诚实。开发人员还假设所有用户将总是使用他们测试过的浏览器访问Web应用程序。还有很多其他的假设。这些开发人员忘记了利用可以免费得到的工具,通过命令行很容易地模拟类似浏览器的行为。事实上,通过在浏览器窗口中键入适当的URL,您可以发送任何"posted"表单,尽管如此,通过禁用这些页面的GET请求,您很容易地阻止这样的"表单发送"。但是,您不能阻止人们模拟甚至创建他们自己的浏览器来入侵您的系统。
根本的问题在于开发人员不能确定客户端验证与服务器端验证的主要差别。两者的主要差别不在于验证究竟发生在哪里,例如在客户端或者在服务器端。主要的差别在于验证背后的目的不同。
  客户端验证仅仅是方便。执行它可为用户提供快速反馈??使应用程序似乎做出响应,给人一种运行桌面应用程序的错觉。
  另一方面,服务器端验证是构建安全Web应用程序必需的。不管在客户端一侧输入的是什么,它可以确保客户端送往服务器的所有数据都是有效的。
  因而,只有服务器端验证才可以提供真正应用程序级的安全。许多开发人员陷入了错误感觉的圈套:只有在客户端进行所有数据的验证才能确保安全。下面是说明此观点的一个常见的示例:
  一个典型的登录页面拥有一个用来输入用户名的文本框和一个输入密码的文本框。在服务器端,某人在接收servlet中可能遇到一些代码,这些代码构成了下面形式的SQL查询:
"SELECT * FROM SecurityTable WHERE username = ’" + form.getParameter("username") + "’ AND password = ’" + form.getParameter("password") + "’;",并执行这些代码。如果查询在结果集的某一行返回,则用户登录成功,否则用户登录失败。
  第一个问题是构造SQL的方式,但现在让我们暂时忽略它。如果用户在用户名中输入"Alice’–"会怎样呢?假设名为"Alice"的用户已经在SecurityTable中,这时此用户(更恰当的说法是黑客)成功地登录。我将把找出为什么会出现这种情况的原因做为留给您的一道习题。
  许多创造性的客户端验证可以阻止一般的用户从浏览器中这样登录。但对于已经禁用了JavaScript的客户端,或者那些能够使用其他类似浏览器程序直接发送命令(HTTP POST和GET命令)的高级用户(或者说黑客)来说,我们又有什么办法呢?服务器端验证是防止这种漏洞类型所必须的。这时,SSL、防火墙等都派不上用场了。

第2课:安全并非是附加物
  如第1课所述,我曾有幸研究过许多Web应用程序。我发现所有的JavaServer Page(JSP)都有一个共同的主题,那就是具有类似下面伪代码的布局:

<%
User user = 
session.getAttribute("User");
if(user == null)
{
// redirect to 
// the logon page…

if(!user.role.equals("manager"))
{
// redirect to the
// "unauthorized" page…
}
%>

<!-
HTML, JavaScript, and JSP
code to display data and
allow user interaction –>

  如果项目使用诸如Struts这样的MVC框架,所有的Action Bean都会具有类似的代码。尽管最后这些代码可能运行得很好,但如果您发现一个bug,或者您必须添加一个新的角色(例如,"guest"或者"admin"),这就会代表一场维护恶梦。
  此外,所有的开发人员,不管您多年轻,都需要熟悉这种编码模式。当然,您可以用一些JSP标签来整理JSP代码,可以创建一个清除派生Action Bean的基本Action Bean。尽管如此,由于与安全相关的代码会分布到多个地方,所以维护时的恶梦仍旧存在。由于Web应用程序的安全是强迫建立在应用程序代码的级别上(由多个开发人员),而不是建立在架构级别上,所以Web应用程序还是很可能存在弱点。
  很可能,根本的问题是在项目接近完成时才处理安全性问题。最近作为一名架构师,我曾在一年多的时间里亲历了某一要实现项目的6个版本,而直到第四版时我们才提到了安全性??即使该项目会将高度敏感的个人数据暴露于Web上,我们也没有注意到安全性。为了更改发布计划,我们卷入了与项目资助人及其管理人员的争斗中,以便在第一版中包含所有与安全相关的功能,并将一些"业务"功能放在后续的版本中。最终,我们赢得了胜利。而且由于应用程序的安全性相当高,能够保护客户的私有数据,这一点我们引以为荣,我们的客户也非常高兴。
  遗憾的是,在大多数应用程序中,安全性看起来并未增加任何实际的商业价值,所以直到最后才解决。发生这种情况时,人们才匆忙开发与安全相关的代码,而丝毫没有考虑解决方案的长期可维护性或者健壮性。忽视该安全性的另一个征兆是缺乏全面的服务器端验证,如我在第1课中所述,这一点是安全Web应用程序的一个重要组成部分。
  记住:J2EE Web应用程序的安全性并非仅仅是在Web.xml 和ejb-jar.xml文件中使用合适的声明,也不是使用J2EE技术,如Java 认证和授权服务(Java Authentication and Authorization Service,JAAS)。而是经过深思熟虑后的设计,且实现一个支持它的架构。

第3课:国际化(I18N)不再是纸上谈兵 
  当今世界的事实是许多英语非母语的人们将访问您的公共Web应用程序。随着电子政务的实行,由于它允许人们(某个国家的居民)在线与政府机构交互,所以这一点特别真实。这样的例子包括换发驾照或者车辆登记证。许多第一语言不是英语的人们很可能将访问这样的应用程序。国际化(即:"i18n",因为在"internationalization"这个单词中,字母i和字母n之间一共有18个字母)使得您的应用程序能够支持多种语言。
  显然,如果您的JSP 页面中有硬编码的文本,或者您的Java代码返回硬编码的错误消息,那么您要花费很多时间开发此Web应用程序的西班牙语版本。然而,在Web应用程序中,为了支持多种语言,文本不是惟一必须"具体化"的部分。因为许多图像中嵌有文字,所以图形和图像也应该是可配置的。在极端的情况下,图像(或者颜色)在不同的文化背景中可能有完全不同的意思。类似地,任何格式化数字和日期的Java代码也必须本地化。但问题是:您的页面布局可能也需要更改。
  例如,如果您使用HTML表格来格式化和显示菜单选项、应用程序题头或注脚,则您可能必须为每一种支持的语言更改每一栏的最小宽度和表格其他可能的方面。为了适应不同的字体和颜色,您可能必须为每一种语言使用单独的样式表。
  显然,现在创建一个国际化的Web应用程序面临的是架构挑战而不是应用程序方面的挑战。一个架构良好的Web应用程序意味着您的JSP页面和所有与业务相关的(应用程序特有的)Java代码都不知不觉地选择了本地化。要记住的教训是:不要因为Java、J2EE支持国际化而不考虑国际化。您必须从第一天起就记住设计具有国际化的解决方案。

第4课:在MVC表示中避免共同的错误 
  J2EE开发已经足够成熟,在表示层,大多数项目使用MVC架构的某些形式,例如Struts。在这样的项目中,我常见到的现象是对MVC模式的误用。下面是几个示例。
  常见的误用是在模型层(例如,在Struts的Action Bean中)实现了所有的业务逻辑。不要忘了,表示层的模型层仍然是表示层的一部分。使用该模型层的正确方法是调用适当的业务层服务(或对象)并将结果发送到视图层(view layer)。用设计模式术语来说,MVC表示层的模型应该作为业务层的外观(Fa?ade)来实现。更好的方法是,使用核心J2EE模式(Core J2EE Patterns)中论述到的Business Delegate模式。这段自书中摘录的内容精彩地概述了将您的模型作为Business Delegate来实现的要点和优点:
  Business Delegate起到客户端业务抽象化的作用。它抽象化,进而隐藏业务服务的实现。使用Business Delegate,可以降低表示层客户端和系统的业务服务.之间的耦合程度。根据实现策略不同,Business Delegate可以在业务服务API的实现中,保护客户端不受可能的变动性影响。这样,在业务服务API或其底层实现变化时,可以潜在地减少必须修改表示层客户端代码的次数。
  另一个常见的错误是在模型层中放置许多表示类型的逻辑。例如,如果JSP页面需要以指定方式格式化的日期或者以指定方式排序的数据,某些人可能将该逻辑放置在模型层,对该逻辑来说,这是错误的地方。实际上,它应该在JSP页面使用的一组helper类中。当业务层返回数据时,Action Bean应该将数据转发给视图层。这样,无需创建模型和视图之间多余的耦合,就能够灵活支持多个视图层(JSP、Velocity、XML等)。也使视图能够确定向用户显示数据的最佳方式。
  最后,我见过的大多数MVC应用程序都有未充分应用的控制器。例如,绝大多数的Struts应用程序将创建一个基本的Action类,并完成所有与安全相关的功能。其他所有的Action Bean都是此基类的派生类。这种功能应该是控制器的一部分,因为如果没有满足安全条件,则首先调用不应该到达Action Bean(即:模型)。记住,一个设计良好的MVC架构的最强大功能之一是存在一个健壮的、可扩展的控制器。您应该利用该能力以加强自己的优势。

第5课:不要被JOPO束缚住手脚
  我曾目睹许多项目为了使用Enterprise JavaBean而使用Enterprise JavaBean。因为EJB似乎给项目带来优越感和妄自尊大的表现,所以有时它是显酷的要素(coolness factor)。而其他时候,它会使J2EE和EJB引起混淆。记住,J2EE和EJB不是同意词。EJB只是J2EE 的一部分,J2EE 是包含JSP、servlet、Java 消息服务(JMS)、Java数据库连接(JDBC)、JAAS、 Java管理扩展(JMX)和EJB在内的一系列技术,同样也是有关如何共同使用这些技术建立解决方案的一组指导原则和模式。
  如果在不需要使用EJB的情况下使用EJB,它们可能会影响程序的性能。与老的Web服务器相比,EJB一般对应用服务器有更多的需求。EJB提供的所有增值服务一般需要消耗更大的内存和更多的CPU时间。许多应用程序不需要这些服务,因此应用服务器要与应用程序争夺资源。
  在某些情况下,不必要地使用EJB可能使应用程序崩溃。例如,最近我遇到了一个在开源应用服务器上开发的应用程序。业务逻辑封装在一系列有状态会话bean(EJB)中。开发人员为了在应用服务器中完全禁用这些bean的"钝化"费了很大的劲。客户端要求应用程序部署在某一商用应用服务器上,而该服务器是客户端技术栈的一部分。该应用服务器却不允许关闭"钝化"功能。事实上,客户端不想改变与其合作的应用服务器的设任何置。结果,开发商碰到了很大的麻烦。(似乎)有趣的事情是开发商自己都不能给出为什么将代码用EJB(而且还是有状态会话bean)实现的好理由。不仅仅是开发商会遇到性能问题,他们的程序在客户那里也无法工作。
  在Web应用程序中,无格式普通Java 对象(POJO)是EJB强有力的竞争者。POJO是轻量级的,不像EJB那样负担额外的负担。在我看来,对许多EJB的优点,例如对象入池,估计过高。POJO是您的朋友,不要被它束缚住手脚。

第6课:数据访问并不能托管O/R映射 
  我曾参与过的所有Web应用程序都向用户提供从其他地方存取的数据,并且因此需要一个数据访问层。这并不是说所有的项目都需要标识并建立这样一个层,这仅仅说明这样层的存在不是隐含的就是明确的。如果是隐含的数据层,数据层是业务对象(即:业务服务)层的一部分。这适用于小型应用程序,但通常与大一些项目所接受的架构指导原则相抵触。
  总之,数据访问层必须满足或超出以下四个标准:
  具有透明性 
  业务对象在不知道数据源实现的具体细节情况下,可以使用数据源。由于实现细节隐藏在数据访问层的内部,所以访问是透明的。
  易于迁移
  数据访问层使应用程序很容易迁移到其他数据库实现。业务对象不了解底层的数据实现,所以迁移仅仅涉及到修改数据访问层。进一步地说,如果您正在部署某种工厂策略,您可以为每个底层的存储实现提供具体的工厂实现。如果是那样的话,迁移到不同的存储实现意味着为应用程序提供一个新的工厂实现。
  尽量减少业务对象中代码复杂性 
  因为数据访问层管理着所有的数据访问复杂性,所以它可以简化业务对象和使用数据访问层的其他数据客户端的代码。数据访问层,而不是业务对象,含有许多与实现相关的代码(例如SQL语句)。这样给开发人员带来了更高的效率、更好的可维护性、提高了代码的可读性等一系列好处。
  把所有的数据访问集中在单独的层上
  由于所有的数据访问操作现在都委托给数据访问层,所以您可以将这个单独的数据访问层看做能够将应用程序的其他部分与数据访问实现相互隔离的层。这种集中化可以使应用程序易于维护和管理。
  注意:这些标准都不能明确地调出对O/R(对象到关系)映射层的需求。O/R映射层一般用O/R映射工具创建,它提供对象对关系数据结构的查看和感知(look-and-feel)。在我看来,在项目中使用O/R映射与使用EJB类似。在大多数情况下,并不要求它。对于包含中等规模的联合以及多对多关系的关系型数据库来说,O/R映射会变得相当复杂。由于增加O/R 映射解决方案本身的内在复杂性,例如延迟加载(lazy loading)、高速缓冲等,您将为您的项目带来更大的复杂性(和风险)。
  为了进一步支持我的观点,我将指出按照Sun Microsystem所普及的实体Bean(O/R映射的一种实现)的许多失败的尝试,这是自1.0版以来一直折磨人的难题。在SUN的防卫措施中,一些早期的问题是有关EJB规范的开发商实现的。这依次证明了实体Bean规范自身的复杂性。结果,大多数J2EE架构师一般认为从实体Bean中脱离出来是一个好主意。
  大多数应用程序在处理他们的数据时,只能进行有限次数的查询。在这样的应用程序中,访问数据的一种有效方法是实现一个数据访问层,该层实现执行这些查询的一系列服务(或对象、或API)。如上所述,在这种情况下,不需要O/R映射。当您要求查询灵活性时,O/R映射正合适,但要记住:这种附加的灵活性并不是没有代价的。
  就像我承诺的那样,在本文中,我尽量避免陈腐的最佳实践。相反,关于J2EE项目中每一位架构师必须做出的最重要的决定,我集中讲解了我的观点。最后,您应该记住:J2EE并非某种具体的技术,也不是强行加入到解决方案中的一些首字母缩写。相反,您应该在适当的时机,恰当的地方,使用合适的技术,并遵循J2EE的指导原则和J2EE中所包含的比技术本身重要得多的实践。