关闭

简化Spring(3)--Controller层

442人阅读 评论(0) 收藏 举报

   MVC不就是把M、V、C分开么?至唯物朴素的做法是两个JSP一个负责View,一个负责Controller,再加一个负责Model的Java Bean,已经可以工作得很好,那时候一切都很简单。

    而现在为了一些不是本质的功能,冒出这么多非标准的Web框架,实在让人一阵郁闷。像Ruby On Rails那样简捷开发,可用可不用,而且没有太多的限制需要学习的,比如Webwork这型还可以考虑。但像Struts那样越用框架越麻烦,或者像 Tapestry那样有严重自闭倾向,额上凿着"高手专用玩具"的,用在团队里就是不负责任的行为了。


    so,我的MVC方案是使用Spring MVC的Controller接口,写最普通的JavaBean作为Controller,本质就和当年拿JSP作Controller差不多,但拥有了Spring IOC的特性。

    之所以用这么消极的选择标准,是因为觉得这一代MVC框架离重回RAD时代的标准还很远,注定了只是一段短暂的,过渡的技术,不值得投资太多精力和团队学习成本。

1. 原理
     Spring MVC按植物分类学属于Martin Flower〈企业应用模式〉里的静态配置型Front Controler,使用DispatchServlet截获所有*.do的请求,按照xml文件的配置,调用对应的Command对象的handleRequest(request,response)函数,同时进行依赖对象的注入。

     我们的Controller层,就是实现handleRequest(request,response)函数的普通JavaBean。

2. 优势
     Spring MVC与struts相比的优势:

     一是它的Controller有着从松到紧的类层次结构,用户可以选择实现只有一个HandleRequest()函数的接口,也可以使用它有很多回调函数的SimpleFormController类。

     二是不需要Form Bean,也不需要Tapestry那所谓面向对象的页面对象,对于深怕类膨胀,改一个东西要动N个地方的人最适合不过。
    
     三是不需要强XML配置文件,宣告式编程是好的,但如果强制成框架,什么都要在xml里面宣告,写的时候繁琐,看的时候也要代码配置两边看才能明白就比较麻烦了。
 
     那Webwork呢?没有实战过,不过因为对MVC框架所求就不多,单用Spring MVC的Controller已经可以满足需求,就不多搞一套Webwork来给团队设坎,还有给日后维护,spring,ww2之间的版本升级添麻烦 了。真有什么需要添加的,Spring MVC源代码量很少,很容易掌控和扩展。
 
3.化简

3.1. 直接implement Controller,实现handleRequest()函数
      首先,simpleformcontroller非我所好,一点都不simple。所以有时我会直接implement Controller接口。这个接口的唯一函数是供Front Controller调用的handleRequest(request,response) , 返回类型是 :ModelAndView

      如果需要application对象,比如想用application.getRealPath()时,就要extends webApplicationObjectSupport。

3.2.每个Controler负责一组相关的action
       我是坚决支持一个Controler负责多个action的, 一个Controler一个action就像一个function一个类一样无聊。所以我用最传统的方式,用URL参数如msg="insert"把一组 相关action交给一个Controler控制。ROR与制作中的Groovy On Rails都是这种模式,Spring也有MultiActionController支持。
       以上三者都是把URL参数直接反射为Controller的函数,而Stripes的设计可用annotation标注url action到响应函数的映射。
      
3.3.xml宣告式编程的取舍
    我的取舍很简单,反正Spring没有任何强制,我只在可能需要不重新编译而改变某些东西的时候,才把东西放在xml里动态注入。jsp路径之类的就统统收回到controller里面定义.
 
3.4.Data Binder
       Data Binder是Controller的必有环节,对于Spring提供的DataBinder,照理完全可用,唯一不爽是对象如果有内嵌对象,如订单对象 里面包含了Customer对象,Spring需要你先自行创建了Customer对象并把它赋给了Order对象,才可能实现 order.customer.customer_no这样的绑定。我偷懒,又拿Jakarta BeanUtils出来自己做了一个Binder。

3.5.提取基类
      最后还是忍不住提取了一个基类,负责MultiAction和其他一些简便的方法。Sprnig的MultiActionController做得太死,规定所有函数的第1,2个参数必须是request和response,不懂动态的,温柔的进行参数注入。
      
      经过化简再化简,已经是很简单一个Java Bean ,任谁都可以轻松上手,即使某年某月技术的大潮把现在所有MVC框架都淹没了,也不至于没人识得维护。 
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:111413次
    • 积分:1441
    • 等级:
    • 排名:千里之外
    • 原创:6篇
    • 转载:116篇
    • 译文:0篇
    • 评论:18条
    最新评论