更简单的框架(2)-Servlet的处理

 在以前，如果别人让我帮他做个网站之类的，我一般不乐意。为什么？工作量大，就比如写个servlet，无论你用javax.servlet.HttpServlet还是用structs等框架来编写，都不轻松。

用servlet吧，参数解析，繁重的编码量会搞得自己很郁闷。那好，用struts，用了struts以后好多了，参数直接给你映射到javabean里了，而且你也可以直接指定调用actionProcessor的某个方法。但是接下来的那一堆配置呢？配错了一点，跑不起来了吧。进一步说，你要想完全发挥struts的威力，你不对他进行1两的年的学习，我只能说很难。配置、api都够学上一段时间。而且当你还想再灵活的时候，恐怕就要和struts的源代码做亲密接触了。

针对小型的应用，我用了另外一种方法，“不采用配置，而根据习惯”。也就是说大部分编程人员都这样做的，我就不再做规定，而直接使用。

大的模型依然是mvc，视图用jsp+jstl，controller用action，model依然是javabean。但是怎样把视图和控制器联系起来呢？这个联系是双向的从视图到controller，然后从controller再到视图。第二个方向不用说了，大家都知道。

第一个方向呢，我模仿struts的做法。但是最大的不同是，我简化了配置：我用一句话来配置所有的action，我指定所有ActionProcessor所在的包名（前提是把他们放到一个包里）。当一个http://localhost:8080/app/ActionCategory!delete.action这样的链接把请求发到服务器时，我就能取到类名ActionCategory和方法名delete，然后利用反射调用delete方法。这样整个过程就完成了。

看一个表单的例子：

< form  method ="post"
                                                action ="${requestScope.contextPath}/ActionCategory!delete.action"
                                                name ="delete" >
                                                 < input  type ="hidden"  value ="${cata.id}"  name ="id" >
                                                 < input  type ="submit"  value =" 删除 "  name ="submit" >
                                             </ form >

再看下action的典型写法：

public   void  delete(HttpServletRequest request, HttpServletResponse response)
             throws  ServletException, SQLException, IOException  ... {
        Product product = (Product) ServletUtil.requestParam2Bean(request,
                Product.class, new String[] ...{ "id", "categoryId" });
        ProductDao.delete(product.getId());
        listByCategoryId(request, response, product.getCategoryId());
    }

再看下所有的配置，仅仅配了一个filter，初始化参数是actionProcessor所在的包名：

     < filter >
         < filter-name > autumnSunshineApp </ filter-name >
         < filter-class > com.zhmt.webapp.FilterAutumnSunshine </ filter-class >
         < init-param >
             < param-name > actionProcessorPackage </ param-name >
             < param-value > com.zhmt.bjmq.action </ param-value >
         </ init-param >
     </ filter >
     < filter-mapping >
         < filter-name > autumnSunshineApp </ filter-name >
         < url-pattern > *.action </ url-pattern >
     </ filter-mapping >

这样，我使用一种相对简单的办法就完成了这个以前要写很多代码和配置，或者大量if else语句才能搞定的东西。而且整个东西是可以复用的，不依赖于任何应用。

到此为止，这个以前最让我烦的东西就搞定了。虽然说现在的ide可以帮我们做配置这类的工作，不可否认，修改和维护所花费的时间是不少的。我这里是使用了约定和自己的coding习惯，直接当作规则来使用，不再另加约束。所以省掉了。

在这一环节中，相对来说比较繁琐和重复的工作就是参数的解析，我做了一个工具ServletUtil，其中一个方法就是直接把参数给解析成javabean。这个纯粹是工作量的东西也省掉了。

mvc中重要的一个环节就是模型了，模型部分我也做了封装，尽量避免配置，而使用习惯。争取更大限度的去除重复的编码。下次有机会再写。