【JSF专家Dennis Byrne】JSF反模式与陷井(一) 博客分类： 专家文章翻译 JSFBean配置管理XML框架

本文不是一篇关于JSF的入门文章。作者Dennis Byrne现在求职于ThoughtWorks，他是Apache Myfaces的项目管理委员会成员，同时又是JBoss JSFUnit的贡献者。由此可见作者有足够的权威去批判JSF。2008年在拉斯维加斯由TheServerSide举行的 Java座谈会上，你会看见Dennis对JSF反模式与陷井的个案研究。

 

本文覆盖了JSF日常开发过程中的反模式与陷阱，包括性能，紧耦合，线程安全，安全问题，互用性以及本身缺陷。好吧，现在开始吧。

 

蹩足脚的setter注入验证

构造函数对domain model(域模型)来说，是放置validation logic(验证逻辑)绝佳的好地方。理想环境下，每一个基于XML配置对象关系映射的框架，都应该支持构造函数依赖注入，这样的话，我们就不需要再为每个字段添加上setter方法了。但理想终究是理想，还是得面对现实。（注：这里讲的验证并非那种在页面输入式的校验，面是类似于Spring启动过程中，对所有其托管的bean的那些依赖属性是否合法的校验）

 

JSF规范为托管的bean定义了一套依赖注入机制。而这个机制setter有，构造函数却没有。我是明白这一点的。JSF只是一个标准的MVC框架，本身不需要什么依赖注入。但往往不幸的是，这也常常让开发人员在开发过程中，因为不清楚这一点，而无法完成对想要的domain验证以及bean的一些初始化逻辑。

 

这种Setter验证的反模式常常发生在这种场景下：原本由构造函数注入的那些参数现在想转移出来，改成setter方式来注入，这样这些属性在这个类里的书写顺序肯定有先有后了。但JSF规范里指出：被托管的bean的那些setter注入的属性必须按顺序依次配置。

 

例：

<managed-bean>
<managed-bean-name>iteration</managed-bean-name>
 	<managed-bean-class>net.dbyrne.agile.Iteration</managed-bean-class>
 	<managed-bean-scope>request</managed-bean-scope>
<managed-property> <!—setStart会最先被调用 -->
		<property-name>start</property-name>
		<value>#{projectBean.currentStart}</value>
 	</managed-property>
 	<managed-property>
		<property-name>end</property-name>
<value>#{projectBean.currentEnd}</value>
 	</managed-property>
 	<managed-property><!—setLast会最后被调用 -->
		<property-name>last</property-name>
		<value>hack</value>
</managed-property>
</managed-bean>

 

 

 

在下面我举例一个Iteration类的例子。如果这个类的作者想将start属性和end属性被托管起来。（根据上面的配置文件与下面的代码，如果Iteration如果没有初始化这些属性是会报错的）除此之外，我们还希望start属性必须小于end属性。这样，我们的代码可以写成：

 

public class Iteration {

private Calendar start, end; // 注入

// 没有start, end 的setters 和 getters 方法

public void setLast(String last) {

   	if(start == null || end == null)
			throw new NullPointerException("incomplete range");

    	if(start.after(end))
			throw new IllegalStateException("start cannot be after end");

}

}

 

 

 

怎么解决这个问题？在JSF1.2中，我们可以使用PostConstruct Annotation，这样PostConstruct Annotation会在被托管的bean(这里指Iteration.class)创建后，再去初始化那个被标为“PostConstruct”的方法，请看：

 

public class Iteration {

private Calendar start, end; // injected

// sans setters and getters for start, end

@javax.annotation.PostConstruct
public void initialize() {

   	if(start == null || end == null)
	  		throw new NullPointerException("incomplete range");

    	if(start.after(end))
	  		throw new IllegalStateException("start cannot be after end");

}
}

 

 

 

在这里使用PostConstruct Annotation是相当有意义，因为当前的Java社区已经开始厌恶基于XML配置的方法，因此这也无形中使得基于Annotation的方式得到不少便宜。但这也并没有从根本上解决问题：Iteration的作者又想要每一个Iteration实体都有自己的start和end属性，而PostConstruct只是保证JSF不会创建非法的Iteration，因此也无法保证去访问一个无参构造函数或setters方法。

 

使用PostConstruct虽然没有糟糕到寸步难行，但应该有更好的办法是将JSF与一个提供完整依赖注入的框架结合起来使用——使用Spring即可。这很容易，在JSF的描述符加上：

 

 

<application>
<variable-resolver>
   	org.springframework.web.jsf.DelegatingVariableResolver
</variable-resolver>
</application>

 

 

当然新发布的Apache MyFaces也已经支持Guice了。

 

 

过度Map Ticket(把戏)

我要说的是对JSF的“Map Ticket”不可原谅。同刚才的Setter验证一样，Map Ticket使用也是JSF规范种种限制的结果。JSF EL，Unified EL都不支持托管bean的参数化函数调用。而目前实现的还只是JSP EL和Facelets直接用static方法的调用，如果你是一个Tapestry开发人员或熟悉OGNL表达式的话，会对此感到失望。

 

而Map恰恰在这里又是唯一可以通过JSP EL，JSF EL以及Unified EL直接调用带参数函数的接口。

 

#{myManagedBean.silvert} // pulls “silvert” from managed bean Map
#{param[“foo”]}          // pulls “foo” request parameter

 

 

这可倒好了，一些JSF开发人员干脆自己实现Map接口，以图方便：

public class MapTrick implements Map {

	public Object get(Object key) {

		return new BusinessLogic().doSomething(key);

	}

	public void clear() { }
	public boolean containsKey(Object arg) { return false; }
	public boolean containsValue(Object arg) { return false; }
	public Set entrySet() {return null; }
	public boolean isEmpty() { return false; }
	public Set keySet() { return null; }
	public Object put(Object key, Object value) { return null; }
	public void putAll(Map arg) { }
	public Object remove(Object arg) { return null; }
	public int size() { return 0; }
	public Collection values() { return null; }

}

 

 

 

这样，只要你通过EL在页面直接调用这些方法，就可以直接被调用（其它的一般只能是setter,getter才能调用）。有一次，我见过一个架构师围绕整个Map弄出了一个小框架。结果可想而知，开发人员都在强烈抱怨视图层与模型层之间的强耦合。

 

 

PhaseListener重复解析faces-config.xml

Apache Software Foundation一直有这么一个非常活跃的邮件列表：[e-mail]。在这里你可以与大家交流新思想，技术上的解决方案，甚至激烈的讨论。这么多年过去了，MyFaces仍然作为一个开源项目持续着，并且我的很多队友还与使用该框架的开发人员联系着。其中有一个臭名昭著的经典的问题“Deja Vu PhaseListener Effect”（指的是两次加载JSF的XML配置文件）。如果你现在用Google搜一下“MyFaces PhaseListeners twice”，你就明白了。

 

好了，我们来看看这种情况怎么发生的。首先，我们在JSF配置文件里注册一个PhaseListeners

 

<lifecycle>
<phase-listener>net.dbyrne.PhaseListenerImpl</phase-listener>
</lifecycle>

接下来在web.xml里配置的context参数又会通过JSF的javax.faces.CONFIG_FILES重新配置一遍：

<context-param>
    <description>comma separated list of JSF conf files</description>
    <param-name>javax.faces.CONFIG_FILES</param-name>
    <param-value>
		/WEB-INF/faces-config.xml,/WEB-INF/burns.xml
    </param-value>
</context-param>

 

为什么PhaseListeners要这么麻烦配置两次？因为所有的JSF实现都会自动的解析存在于/WEB-INF/faces-config.xml文件。同样，在context参数中，逗号间隔的文件也会解析。如果/WEB-INF/faces-config.xml文件也出现在context的参数中的话，就意味着这个配置文件要解析两次了。从而在程序启动过程中，faces-config.xml里注册的那些配置也要重复注册两次。

 

 

文章还是太长了，但后续部分更加精彩...........