Spring MVC的常见错误

10年前我开始自己的职业生涯的时候，Struts还是市场上的主流标准。然而多年过后，我发现Spring MVC已经越来越流行了。对我而言这并不意外，因为它能和Spring容器无缝集成，同时它还提供了灵活性及扩展性。

从我迄今为止对Spring的经验来看，我发现有不少人在配置Spring的时候经常会犯一些常见的错误。跟使用Struts框架相比，这些错误要出现得更频繁一些。我猜想这可能是它在可用性和灵活性之间做出的权衡。不仅如此，Spring的文档中全是例子但缺少解释。为了填充这一空白，本文准备深入阐述三个大家常犯的错误。


在Servlet上下文定义文件中声明bean

我们都知道，Spring使用的是ContextLoaderListener来加载Spring的应用上下文（application context）。还有就是在声明 DispatcherServlet的时候，我们需要用"${servlet.name}-context.xml”的名字来创建servlet的上下文定义文件。你有想过为什么要这样吗？

应用上下文结构

并非所有的人都清楚，Spring应用上下文其实是分层的。我们看一下这个方法

org.springframework.context.ApplicationContext.getParent()

它告诉我们，Spring应用上下文，其实是有父context的。那么，它是用来干什么的？

如果你下载一下源码，搜索一下方法引用，你会发现 Spring Application Context把双亲作为它的扩展。如果你不想读源码的话，我来给你演示一下BeanFactoryUtils.beansOfTypeIncludingAncestors()方法的一个用法 ：

if (lbf instanceof HierarchicalBeanFactory) {
    HierarchicalBeanFactory hbf = (HierarchicalBeanFactory) lbf;
    if (hbf.getParentBeanFactory() instanceof ListableBeanFactory) {
 Map parentResult = 
              beansOfTypeIncludingAncestors((ListableBeanFactory) hbf.getParentBeanFactory(), type);
 ...
    }
}
return result;
}

如果你看完整个方法，你会发现 Spring Application Context 会先在内部的上下文中查找bean，然后再去搜索父context。通过这个策略，Spring可以进行高效的反向广度优先搜索。




ContextLoaderListener


每个开发人员都应该了解这个类。它能帮忙你从预定义的上下文定义文件中加载Spring应用上下文。由于它实现了ServletContextListener接口，因此一旦WEB应用加载完毕，就会立即加载Spring的上下文。毋庸置疑，当加载包含@PostContruct注解或者批处理任务的Spring容器时，这个会非常有用。

反过来，任何在servlet上下文定义文件中定义的bean在servlet初始化前都不会构造。那servlet在何时会被初始化呢？这个是不确定的。最坏的情况下，你可能得等到用户第一次点击对应的servlet所映射的URL的时候，才会加载Spring上下文。

知道了以上这些信息，你认为你的bean声明应该放在哪里好呢？我觉得最佳的位置就是ContextLoaderListener所加载的上下文定义中了，没有其它。这里有个技巧就是将ApplicationContext作为servlet的一个属性进行存储，

org.springframework.web.context.WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE   

然后，DispatcherServlet会从ServletContext中加载这个上下文，并把它赋值给上层的应用上下文。

protected WebApplicationContext initWebApplicationContext() {
   WebApplicationContext rootContext =
      WebApplicationContextUtils.getWebApplicationContext(getServletContext());
   ...
}

由于它的这个行为 ，我强烈建议你只创建一个空的servlet应用上下文定义文件，将你的bean定义在父context中。这能避免当WEB应用加载时bean的重复创建，并能保证批处理作业能立即执行。


理论上说，将bean定义在servlet应用上下文定义文件中会使得bean对该servlet是唯一可见的。然而，在我8年的Spring使用经验来看，我发现这个特性几乎没有什么用处，除了用来定义 WEB service端点。

在ContextLoaderListener后面声明Log4jConfigListener


这是一个小BUG，不过如果你不注意的话，它会让你栽跟头。Log4jConfigListener是我最喜欢的解决-Dlog4j.configuration问题的一个方案，这样我们可以控制log4j的加载而不用改变服务器启动的进程。

很明显，这应该是你在web.xml中声明的第一个监听器。否则，你所声明的所有日志配置都将不会生效。


重复的bean定义


在早期的Spring中，开发人员更多的时间是花在了配置XML文件上，而不是Java类。对每一个新的bean，我们都需要声明它，然后自己将依赖注入，尽管这个做法很干净，整洁，但却非常痛苦。所以后续版本的Spring在可用性上进行了很大的提升这也不足为奇了。现在来说，开发人员只需要声明事务管理器，数据源，属性源，WEB服务endpoint，剩下的工作就交给组件扫描与自动织入来完成吧。

我喜欢这些新特性，但是权利越大，责任越大，否则的话，事情很快就会变得一团糟。XML文件中的组件扫描与bean声明是完全独立的。因此，在同一个bean容器内，如果bean被注解为组件扫描并且是手动声明的，就很有可能会出现相同类的不同bean。所幸的是，这种错误一般只发生在新手身上。

当我们需要集成一些嵌入式组件的时候，事情就变得复杂了。这个时候我们就需要一种策略来避免重复的bean声明。



上图展示了我们在日常工作中可能面临的真实案例。大多数时候，系统是由多个组件组成 的，一个组件服务于多个产品。每个应用和组件都有自己的bean。在这个例子中，怎么做才能最好地避免bean的重复声明？

下面是我个人提出的一个策略：

确保每个组件都以一个独特的包名开头。这样当我们需要组件扫描的时候会更容易一些。

不要让开发组件的团队将bean声明在组件内部（注解 VS XML声明）。负责将组件打包成最终产品的开发人员，他应该得去确保bean声明是唯一的。

如果在组件内部有上下文定义文件，最好将它放在某个包底下，而不是classpath的根目录下。如果能给它分配一个专门的名字则更好。比如说，src/main/resources/spring-core/spring-core-context.xml总比src/main/resource/application-context.xml要好。想像一下如果你打包组件的时候发现同一个包底下存在相同的application-context.xml你会是什么心情。

如果你已经将bean声明在一个context文件中了，就不要提供任何组件扫描的注解(@Component, @Service or @Repository)。

不要在通用包上进行组件扫描。比如说，不要扫描org.springframework，扫描子包的话会更容易管理，比如说org.springframework.core, org.springframework.context, org.springframework.ui。

原创文章转载请注明出处：http://it.deepinmind.com

英文原文链接