文章分类:Java编程
3.0版是完全兼容2.5,因此了解2.5版的@MVC则更容易接受。正如Arjen Poutsma小伙子在他的博客里说的那样,3.0时代将集中致力于表述性状态转移(REST,希望我没有翻译错,金山词霸翻译为“休息”)的网络服务和更容易的网络编程。的确增加了更多的控制器类型,并增强了SOAP/WSDL/WS这些基于分布式体系结构。
先回忆下2.5注解方式的@MVC,来一个示例:
@Controller
public class ArticleController{
@RequestMapping("/articleView")
public String getArticle(@RequestParam("id") String id, HttpServletRequest request){
request.setAttribute("article", service.find(Article.class, id));
return "articleView";
}
}
ArticleController没有实现任何接口,是一个最普通不过的pojo,如果浏览器来了articleView.do?id=xxx这个请求,Spring会找到getArticle()这个方法,该方法第一个参数绑定到了URL上的请求参数,第二个是J2EE标准的request对象(可见Spring MVC是非侵入式的,不像变态的Struts2),事实上还可以给定HttpServletResponse,ModelMap,甚至自己的类型,Spring都会为你将值传入进来。通过一个逻辑层service组件根据id参数值去底层查找Article对象,并放入request作用域中,最后返回的是面页视图名,这个例子中是返回到articleView.jsp中。
上例再变通下:
@Controller
public class ArticleController{
@RequestMapping("/articleView_*")
public String getArticle(HttpServletRequest request){
String id = StringUtil.getParam(request.getRequestURI(),"articleView_*");
request.setAttribute("article", service.find(Article.class, id));
return "articleView";
}
}
对于articleView_aaa.do,articleView_bbbb.do,articleView_c5h8j2.do,articleView_xxx.do,这样的请求都会由getArticle()这个方法来应付,是不是很有意思?
Spring 3.0增加了一个@ PathVariable注解来支持可变的请求路径,将上面的代码在3.0版中再变通下:
@Controller
public class ArticleController{
@RequestMapping("/articleView/${id}") //可以接受articleView/aaa.do,articleView/xxx.do...
public String getArticle(@PathVariable String id, HttpServletRequest request){
request.setAttribute("article", service.find(Article.class, id));
return "articleView";
}
}
再变得复杂些:
@Controller
public class ArticleController{
@RequestMapping("/articleList/${pageSize}/channel/*/category/${id}")
public String getArticles((@PathVariable Integer pageSize, @PathVariable int id, HttpServletRequest request){
Integer channelId = StringUtil.getParam(request.getRequestURI(),"channel/*/");
request.setAttribute("articles", service.findScroll(Article.class, pageSize,50,"channel=? and category=?",new Object[]{channelId,id}));
return "articleList";
}
}
它已经灵活到URL地址完全可以自己随意编制。
根据内容协商制的视图解析机制:
2.5版是由@MVC控制器来决定视图解析器,3.0版将变得更加灵活,似乎可以通过扩展名来转到不同的解析器中,例如请求一个.pdf文件将是如何效果呢?3.0版都会带来不可思议的模式。
HTTP方法的转换:
先看前台页面一段Html代码
<form:form method="delete">
<p class="submit"><input type="submit" value="Delete Pet"/></p>
</form:form>
HTTP规范中form表单只有两种方法——POST和GET,而3.0做了一个过滤器,可以转换这些方法至四种——GET, PUT, POST, 和 DELETE。控制器接受请求:
@Controller("/deleteArticle")
public class ArticleController{
@RequestMapping(method = RequestMethod.DELETE)
public String deleteArticle(@PathVariable String id, HttpServletRequest request){
service.delete(Article.class, id);
return "message";
}
}
3.0版仅在MVC子集中就增加了很多新特性,如果在IoC、AOP等等其它子集所有的变革,绝对可以称得上Srping创始人所述的里程碑版本。3.0版使用的注解列表如下:
• @Autowired
• @Component
• @Controller
• @InitBinder
• @ManagedAttribute
• @ManagedOperation
• @ManagedOperationParameters
• @ManagedOperationParameter
• @ManagedResource
• @PathVariable
• @PostConstruct
• @PreDestroy
• @Repository
• @RequestMapping
• @Required
• @Resource
• @Service
• @Transactional
目前Spring 3版本已经到了M2,应该是M3完成后将推出最终正式版本,我想很快会来临,按照Spring的创始人罗德.约翰逊的预言,未来J2EE应用中Spring+Tomcat将占主导地位,是否引起争议,笔者不敢点评,不过Oracle收购Sun后,Java社区将是如何,还无从知晓,似乎罗德.约翰逊对这宗收购案也有些紧张,因为Oracle不像Sun的第一个谈判者IBM那样有过开放技术的先例(可以回忆下IBM早期的主板总线开放掀起的兼容机潮至今波涛不熄)。目前国内对新东西消化尚慢,我到图书城看了下,Spring 2.5的资料都很难找到。且很多企业都是抱着Struts1.x在做开发,尽管笔者这样说会引来很多争议,但Struts1时代的灭亡只是时间问题。Struts2虽然改进了很多,依笔者看,与Spring MVC相比仍有诸多的不足,尤其看不惯那种变态的侵入模式,看看它把HttpServletRequest、HttpSession、HttpServletResponse等servlet标准组件干成什么样?开源时代,至少我不愿意接受那种变态的潜规则。
笔者早先常用Struts1.x框架,它搭配了一套自己的ActionForm,使得编程工作量增加,虽然可以变通使用自己的Pojo,但对于没有掌握J2EE底层工具类(BeanUtil)的开发人员来说,其类型匹配是非常复杂的事。事实上Spring MVC早在1.x版本就完全使用自己的pojo来对应表单的填充,配上属性编辑器,可以解决类型转换问题,完全实现领域模型驱动的设计模式。由于MVC层的控制器也是Spring容器的Bean而已,因此对整个项目的控制、扩展变得非常容易。同时上文也顺便点评了Struts2,可见Spring MVC在各类MVC框架的优势所在。本身罗德.约翰逊先生是设计模式高手,一个优秀的框架给我们带来的远远不只是开发效率,还有更先进的开发模式和理念...
先回忆下2.5注解方式的@MVC,来一个示例:
@Controller
public class ArticleController{
@RequestMapping("/articleView")
public String getArticle(@RequestParam("id") String id, HttpServletRequest request){
request.setAttribute("article", service.find(Article.class, id));
return "articleView";
}
}
ArticleController没有实现任何接口,是一个最普通不过的pojo,如果浏览器来了articleView.do?id=xxx这个请求,Spring会找到getArticle()这个方法,该方法第一个参数绑定到了URL上的请求参数,第二个是J2EE标准的request对象(可见Spring MVC是非侵入式的,不像变态的Struts2),事实上还可以给定HttpServletResponse,ModelMap,甚至自己的类型,Spring都会为你将值传入进来。通过一个逻辑层service组件根据id参数值去底层查找Article对象,并放入request作用域中,最后返回的是面页视图名,这个例子中是返回到articleView.jsp中。
上例再变通下:
@Controller
public class ArticleController{
@RequestMapping("/articleView_*")
public String getArticle(HttpServletRequest request){
String id = StringUtil.getParam(request.getRequestURI(),"articleView_*");
request.setAttribute("article", service.find(Article.class, id));
return "articleView";
}
}
对于articleView_aaa.do,articleView_bbbb.do,articleView_c5h8j2.do,articleView_xxx.do,这样的请求都会由getArticle()这个方法来应付,是不是很有意思?
Spring 3.0增加了一个@ PathVariable注解来支持可变的请求路径,将上面的代码在3.0版中再变通下:
@Controller
public class ArticleController{
@RequestMapping("/articleView/${id}") //可以接受articleView/aaa.do,articleView/xxx.do...
public String getArticle(@PathVariable String id, HttpServletRequest request){
request.setAttribute("article", service.find(Article.class, id));
return "articleView";
}
}
再变得复杂些:
@Controller
public class ArticleController{
@RequestMapping("/articleList/${pageSize}/channel/*/category/${id}")
public String getArticles((@PathVariable Integer pageSize, @PathVariable int id, HttpServletRequest request){
Integer channelId = StringUtil.getParam(request.getRequestURI(),"channel/*/");
request.setAttribute("articles", service.findScroll(Article.class, pageSize,50,"channel=? and category=?",new Object[]{channelId,id}));
return "articleList";
}
}
它已经灵活到URL地址完全可以自己随意编制。
根据内容协商制的视图解析机制:
2.5版是由@MVC控制器来决定视图解析器,3.0版将变得更加灵活,似乎可以通过扩展名来转到不同的解析器中,例如请求一个.pdf文件将是如何效果呢?3.0版都会带来不可思议的模式。
HTTP方法的转换:
先看前台页面一段Html代码
<form:form method="delete">
<p class="submit"><input type="submit" value="Delete Pet"/></p>
</form:form>
HTTP规范中form表单只有两种方法——POST和GET,而3.0做了一个过滤器,可以转换这些方法至四种——GET, PUT, POST, 和 DELETE。控制器接受请求:
@Controller("/deleteArticle")
public class ArticleController{
@RequestMapping(method = RequestMethod.DELETE)
public String deleteArticle(@PathVariable String id, HttpServletRequest request){
service.delete(Article.class, id);
return "message";
}
}
3.0版仅在MVC子集中就增加了很多新特性,如果在IoC、AOP等等其它子集所有的变革,绝对可以称得上Srping创始人所述的里程碑版本。3.0版使用的注解列表如下:
• @Autowired
• @Component
• @Controller
• @InitBinder
• @ManagedAttribute
• @ManagedOperation
• @ManagedOperationParameters
• @ManagedOperationParameter
• @ManagedResource
• @PathVariable
• @PostConstruct
• @PreDestroy
• @Repository
• @RequestMapping
• @Required
• @Resource
• @Service
• @Transactional
目前Spring 3版本已经到了M2,应该是M3完成后将推出最终正式版本,我想很快会来临,按照Spring的创始人罗德.约翰逊的预言,未来J2EE应用中Spring+Tomcat将占主导地位,是否引起争议,笔者不敢点评,不过Oracle收购Sun后,Java社区将是如何,还无从知晓,似乎罗德.约翰逊对这宗收购案也有些紧张,因为Oracle不像Sun的第一个谈判者IBM那样有过开放技术的先例(可以回忆下IBM早期的主板总线开放掀起的兼容机潮至今波涛不熄)。目前国内对新东西消化尚慢,我到图书城看了下,Spring 2.5的资料都很难找到。且很多企业都是抱着Struts1.x在做开发,尽管笔者这样说会引来很多争议,但Struts1时代的灭亡只是时间问题。Struts2虽然改进了很多,依笔者看,与Spring MVC相比仍有诸多的不足,尤其看不惯那种变态的侵入模式,看看它把HttpServletRequest、HttpSession、HttpServletResponse等servlet标准组件干成什么样?开源时代,至少我不愿意接受那种变态的潜规则。
笔者早先常用Struts1.x框架,它搭配了一套自己的ActionForm,使得编程工作量增加,虽然可以变通使用自己的Pojo,但对于没有掌握J2EE底层工具类(BeanUtil)的开发人员来说,其类型匹配是非常复杂的事。事实上Spring MVC早在1.x版本就完全使用自己的pojo来对应表单的填充,配上属性编辑器,可以解决类型转换问题,完全实现领域模型驱动的设计模式。由于MVC层的控制器也是Spring容器的Bean而已,因此对整个项目的控制、扩展变得非常容易。同时上文也顺便点评了Struts2,可见Spring MVC在各类MVC框架的优势所在。本身罗德.约翰逊先生是设计模式高手,一个优秀的框架给我们带来的远远不只是开发效率,还有更先进的开发模式和理念...