Web开源框架Rose简介

Rose 是由 人人网、糯米网 提供的、基于Servlet规范、Spring“规范”的开放源代码WEB开发框架。

Rose的开源地址是：http://code.google.com/p/paoding-rose/

本文不打算为您详细介绍Rose，而且假设你已经对Rose已经有一些了解，本文的中心是自己初次接触Rose后的一点感言。

作者眼中的Rose哲学

• 基于IoC容器 (使用Spring 2.5.6)
• 收集最佳实践，形成规范和惯例，引导按规范惯例，简便开发
• 收集通用功能，形成一些可使用的组件，提高生产效率
• 特性的插拔，使用基于组合而非继承的设计
• 提供可扩展的点，保持框架的可扩展性
• 注重使用简易性的同时，注重内部代码设计和实现

我对Rose的理解

一句话

基于spring的组件框架，推崇页面驱动和约定优于配置。

Rose中的controller是什么？

你可以简单的把它理解为MVC模式中的controller，但它的意义远不止于此，Rose中的Controller可以说把页面驱动和约定优于配置表现的淋漓尽致，它扮演接收处理web请求职责的对象类，接收web请求传入的参数、调度服务处理业务、将处理结果设置到model中，返回一个指示(页面)。

一个好的web开发框架是什么？在我认为，那就是利于理解（MVC模式）和维护、快速响应开发需求、提高开发效率以及不俗的性能表现。

简单来说，controller代表一个用例中的角色，而它的action方法则代表角色的行为，它使开发人员把精力更加注重业务逻辑的实现。

举一个简单的例子，相信很多网站都有用户注册和登录等功能，下面是其用例图：

 那么URI设计为（一种可能的方案）：

修改信息	user/${userId}/update
登录	user /login
注册	user /register
修改密码	user /${userId}/updatePsw
退出登录	user/logout

从上面我们可以一眼看出，这个controller接收这些请求都是围绕着user这个角色，所以我们抽象出UserController这个对象，而它所产生的行为（URI）正好对应各个action方法。

另外，从命名规则上看，作者建议controller类采用名词，action方法采用动词，这的确是一个不错的实践。

OK！我们只要再写几个页面就可以简单的把这个请求框架搭起来，接下来我们将大部分的精力就放在login、register等业务逻辑的实现，很显然，这提高了我们的开发效率。

 

到这里，你肯定要问，写好了controller，Rose是怎么将实际的请求映射到action方法的呢，这之间肯定有一个约定，这个约定就是请求的URL和所在controller包路径、controller类名称、类自定义uri path注解、action方法，method注解以及注解中的uri匹配参数（具体的匹配规则这里不再赘述）息息相关，这里是Rose的精华所在，也是体现约定的精华所在。

但在技术上，要找到特定action方法，肯定免不了使用反射来达到这一目的，但使用反射会不会对Rose框架的性能有什么大的影响呢？（作者说“我们 有办法 通过在运行时自动进行代码增强包装成Command而不使用类反射来实现目的”，不太明白这句话的含义，望高人指示！）。

实际上，在Rose启动时，Rose会“浏览”controller类和其action方法以及两者相关的注解，形成一个Rose匹配树，这个匹配树的形成意味着Rose已经把所有URI映射规则以及尽可能做的事事先做好(包括对method方法名以及相关要素的缓存)，使Rose在服务状态时，不用再通过类反射来做和类、方法有关的识别和判断，直接就可以从缓存里获取method对象以及相关的其他要素进行处理。这是使用空间来交换时间的最佳例证，在服务状态完全不使用反射也是不可能的，比如运行时访问开发者自定义的action方法肯定要通过method.invoke方法调用(对于代理对象的，使用Proxy来调用)，还有就是在提交表单时，如果action方法参数是一个POJO，那么就需要通过反射将表单里的值动态设置到这个Bean属性中。

Rose眼中的MVC模型

根据MVC的定义：

 

• （控制器Controller）- 负责转发请求，对请求进行处理。
• （视图View） - 界面设计人员进行图形界面设计。
• （模型Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

Rose的controller可以理解为MVC中的C，JSP和velocity可以理解为view，那么model呢？这部分通常是调用业务逻辑充血对象或者自己实现相应的service ，这也是开发人员最应该关注的地方。下图是Rose眼中的MVC，画的比较简陋：

 其中的invocation对象应该引起你的注意，作者对invocation下的定义是：

“通常意义上的“Invocation”是指一次调用，特别地是指对方法的一次调用，是对“一次调用”的抽象与封装，比如包含了调用的输入参数、被调用的对象与方法等等。

在Rose框架下，最终的处理者应该是某个控制器方法，与之相关的还有参数解析器、验证器以及知名度较高的拦截器。为了封装与一次请求处理相关的数据，我们设计了一个Invocation类来表示。”

 

Rose和filter

Rose的入口是net.paoding.rose.RoseFilter，在它背后是一个责任链，采用filter的好处是更加灵活，servlet的映射比较笨拙，一旦处理不了，Servlet规范没有提供机制使得可以由配置在web.xml的其他正常组件处理 (除404，500等错误处理组件之外)。

采用filter的另一个好处是，用作者的话来说，Rose可以很好地和其他web框架兼容。它能够优先处理认定的事情，如无法处理再交给其它Filter、Servlet或JSP来处理，这在改造遗留系统、对各种uri的支持具有天然优越性。正是使用过滤器，Rose不再要求请求地址具有特殊的后缀。

 

拦截器

先来一个简单的推理，某些uri需要做权限设计，一般是在“特定的条件”下才能访问这个uri，根据Rose的uri映射规则，一个uri对应一个action方法，也就是说我们需要标识在“特定的条件”下才能访问这个action方法。

为了更加准确模拟现实世界中这样的约定，我们用注解来表示“特定的条件”，一般这样的注解没有值，只是个标签，它的职责是“表明”，至于表明之后做什么，由拦截器来实现。

比如有些uri需要登录之后才能访问，首先定义@LoginRequired来表示“需要登录”，然后把它放在你认为需要登陆之后才能访问的action方法上（放在类上表示其所有的方法都生效），接下来写一个拦截器，用来实现在访问标识“@LoginRequired”的action方法之前，检查用户是否登录，如果登录则继续执行，如果没有登录则重定向到登陆页面。