13.11. 惯例优先原则（convention over configuration）

ITeedu.com

站内搜索:

Web ITEEDU

博客 汇编 C/C++ JAVA Python Ruby J2EE PHP 我的网盘

手机 IDE 嵌入式 Linux OS MYSQL sqlite 作品 OpenSource

导航： 首页>   webtech  >   j2ee  >   spring25cn  >当前页

13.11. 惯例优先原则（convention over configuration）

对于很多项目来说，严格遵从已有惯例和使用合理的缺省选项大概是这些项目需要的……现在Spring Web MVC明确的支持了这种惯例优先原则的主旨。 这意味着，如果建立了一套命名规范，诸如此类，就可以显著地减少系统所需配置项目的数量， 来建立处理器映射、视图解析器、ModelAndView实例，等等。 这为快速原型开发提供了很大方便。同时提供了一定程度的（通常是好事情）代码库的一致性，进而可以从中选择并发展为成型产品。

提示

Spring分发版本包含了一个展现了惯例优先原则支持的Web应用程序，我们将在这一节描述这一原则。 这个应用程序可以在samples/showcases/mvc-convention目录中找到。

惯例优先原则支持体现在MVC的三个核心领域：模型、视图和控制器。

13.11.1. 对控制器的支持：ControllerClassNameHandlerMapping

ControllerClassNameHandlerMapping类是HandlerMapping接口的一个实现。 它使用惯例来确定请求的URL和用于处理它们的Controller实例间的映射关系。

举个例子，考虑下面的（直观的）Controller实现， 请特别注意这个类的名称。

public class ViewShoppingCartController implements Controller {

    public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) {
        // the implementation is not hugely important for this example...
    }
}

下面是与之伴随的Spring Web MVC配置文件的一个片段：

                
viewShoppingCart" class="x.y.z.ViewShoppingCartController">
    

ControllerClassNameHandlerMapping在它的应用上下文中找出所有不同的处理器（handler）（或Controller）bean， 并去掉名称中的Controller，来定义它的处理器映射。

让我们看更多的例子，这样其中的中心思想就马上就清楚了。

• WelcomeController映射到“/welcome*”请求URL

• HomeController映射到“/home*”请求URL

• IndexController映射到“/index*”请求URL

• RegisterController映射到“/register*”请求URL

• DisplayShoppingCartController映射到“/displayshoppingcart*请求URL

  （注意大小写——全部小写——对于驼峰式大小写（第一个词的首字母小写，随后的每个词首字母大写）的Controller类名。）

当控制器是MultiActionController处理器类时，生成的映射就（有一点点）更为复杂，但幸而没有更难理解。 下面例子中的几个Controller名字假设都是MultiActionController的实现。

• AdminController映射到“/admin/*”请求URL

• CatalogController映射到“/catalog/*”请求URL

如果遵循漂亮而且标准的规范把你的Controller实现命名为xxxController， 那么ControllerClassNameHandlerMapping将使你免于忍受必须首先定义它们， 然后还要维护冗——长——的——SimpleUrlHandlerMapping（或者类似的东西）的枯燥。

ControllerClassNameHandlerMapping是AbstractHandlerMapping的子类， 从而使你能够像对待大量其他HandlerMapping实现一样的定义HandlerInterceptor实例和其他任何东西。

13.11.2. 对模型的支持：ModelMap（ModelAndView）

ModelMap类首先是一个绚丽的Map实现， 它可以使新增的将要显示在View中（或上）的对象也遵循同一命名规范。 考虑下面的Controller实现，注意对象被加入ModelAndView， 而并没有指定任何名称。

public class DisplayShoppingCartController implements Controller {

    public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) {
        
        List cartItems = // get a List of CartItem objects
        User user = // get the User doing the shopping
        
        ModelAndView mav = new ModelAndView("displayShoppingCart"); <-- the logical view name

        mav.addObject(cartItems); <-- look ma, no name, just the object
        mav.addObject(user); <-- and again ma!

        return mav;
    }
}

ModelAndView类使用的ModelMap类是一个自定义的Map的实现。 当有一个新对象加入的时候，它就被用于为这个对象自动生成一个键。 决定某个加入的对象的名字的策略是，当它是一个标量对象（scalar object），比如User时， 就使用这个对象所属类的简短类名。下面的几个例子中，几个为标量对象生成的名字被加入ModelMap实例中。

• 将会为一个新增的x.y.User实例生成“user”作为名称

• 将会为一个新增的x.y.Registration实例生成“registration”作为名称

• 将会为一个新增的x.y.Foo实例生成“foo”作为名称

• 将会为一个新增的java.util.HashMap实例生成“hashMap”作为名字（在这个情形下你可能想要让名字更加明确一些，因为“hashMap不太直观）。

• 新增null将会导致抛出一个IllegalArgumentException。 如果正在加入的这个（或这些）对象可能潜在的是null的话，就要让名字更明确一些。

什么？不能自动生成复数？

Spring Web MVC的惯例优先原则的支持内容中不包括自动生成复数。 这就是说，当加入一个Person对象的List到一个ModelAndView时， 不要指望生成的名字会是“people”。

这是经过一系列讨论之后作出的决定，最后“最小惊讶原则（Principle of Least Surprise）”胜出。

在加入一个Set、List或者对象数组之后， 生成名称的策略是深入这个集合，取出集合中第一个对象的简短类名，并使用这个名称并在后面加上List。 一些例子将会让集合的名称生成方式更清晰……

• 将会为一个新增的包含了一个或多个x.y.User元素的x.y.User[]实例生成“userList”作为名称

• 将会为一个新增的包含了一个或多个x.y.User元素的x.y.Foo[]实例生成“fooList”作为名称

• 将会为一个新增的包含了一个或多个x.y.User元素的java.util.ArrayList实例生成“userList”作为名称

• 将会为一个新增的包含了一个或多个x.y.Foo元素的java.util.HashSet实例生成“fooList”作为名称

• 一个空java.util.ArrayList根本不会被加入（也就是说，addObject(..)调用其实什么都没做）。

13.11.3. 对视图的支持：RequestToViewNameTranslator

RequestToViewNameTranslator接口的功能是当没有显式的提供这样一个逻辑视图名称的时候， 确定一个逻辑的View名称。 这个接口只有一个实现，精明的命名为DefaultRequestToViewNameTranslator。

为了解释DefaultRequestToViewNameTranslator将请求的URL映射到逻辑的视图名的方式， 最好还是求助于一个例子。

public class RegistrationController implements Controller {
                
    public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) {
        // process the request...
        ModelAndView mav = new ModelAndView();
        // add data as necessary to the model...
        return mav;
        // notice that no View or logical view name has been set
    }
}

请注意，在这个handleRequest(..)方法的实现中， 没有在返回的ModelAndView上设置任何的View或者逻辑视图名称。 而是把从请求的URL生成一个逻辑视图名称的任务交给了DefaultRequestToViewNameTranslator。 在上面这个RegistrationController与ControllerClassNameHandlerMapping联合使用的例子中， 一个“http://localhost/registration.html”请求URL将会由DefaultRequestToViewNameTranslator生成一个“registration”逻辑视图名称。 这个逻辑视图名称接下来就会被InternalResourceViewResolver bean解析为“/WEB-INF/jsp/registration.jsp”视图。

提示

甚至不需要显式的定义一个DefaultRequestToViewNameTranslator bean。 如果DefaultRequestToViewNameTranslator的缺省设置符合你的要求， 就可以依赖这样一个事实，Spring Web MVC的DispatcherServlet将会在没有显式配置的情况下自动的生成这个类的一个实例。

当然，如果需要修改缺省设置，那么就需要显式的配置自己的DefaultRequestToViewNameTranslator bean。 关于可以设置的各种属性的细节，请参阅DefaultRequestToViewNameTranslator的相当详细的Javadoc。