【回顾】Struts封装MVC辛酸史

前情回顾

前一段时间由于个人原因对于SSH的学习并没有进行的很彻底，这让我在这块儿的学习感到很空虚。于是借这篇博客来重新温习一下Struts的演变过程。

历史演变

在真正了解struts封装过程前，我们必须要回顾一下servlet的实现原理。

servlet实现原理

还记得这张图吗？

Struts产生前

在Struts产生前，我们的代码是怎么写的，你还记得吗？
1、首先根据上图servlet实现原理，需要在配置文件中配置servlet的请求路径，没增加一个请求就必须增加一个路径的配置。
2、当请求发送给服务器时，servlet可以接收请求。此时，每增加一个请求，就会增加一个servlet的实现类。
3、返回页面时，根据每一个servlet对应功能的需求来返回自己的页面jsp。
于是乎，产生这样一种效果：看图

这样只会让我们的程序越来越混乱！

ActionServlet的产生

于是我们针对于“无限多的servlet”进行优化。将servlet的配置路径用一种规则来代替，将所有的请求都转发到同一个servlet中
（配置路径只需要一次）。
我们把这样一个公共的servlet叫做ActionServlet.然后，我们对传过来的路径进行截取，获取对功能真正有用的部分，进而匹配各自对应的业务逻辑。

String requestURI=request.getRequestURI();
//路径截取，这个是根据自己的路径匹配规则进行的
String path=requestURI.substring(requestURI.indexOf("/",1),requestURI.indexOf("."));
String username=request.getParameter("username");
UserManager userManager=new UserManager();
if("servlet/delUser".equals(path)){
    userManager.del(username);
    request.getRequestDispatcher("/del_sucess.jsp").forward(request,response);
}else if("servlet/addUser".equals(path)){
    userManager.add(username);
    request.getRequestDispatcher("/add_sucess.jsp").forward(request,response);
}else{
    throw new Exception("路径不匹配！");
}

我们可以看出，这样虽然路径配置少了，但是ActionServlet中却多了很多的if Else，如果功能增多，就会破坏OSP，所以，我们并不满意！

抽象ActionServlet

针对Action继续优化，先将公共的部分单独抽象成一个类。

如图，我们让具体的业务Action（AddUserAction,delUserAction）去执行每一个功能对应的业务逻辑，以及最后要转发的页面。
这样在ActionServlet就会产生对业务Action父类的依赖。根据客户端的具体请求，来实例化具体的子类Action。
但是这样并不能解决根本性的问题——if...else，osp问题。

配置文件+反射

我们知道反射是解决if..else的绝妙杀手。
在这里当然也不例外，所以我们可以将请求的路径和要匹配的具体的子类的业务Action（AddUserAction,delUserAction）配置到配置文件中
利用反射来获取路径对应的子类。这样既解决了servlet问题，又符合了OSP原则。两全其美嘛。

最终实现思路

将每一个业务逻辑的子类Action中所包含的信息封装成一个ActionMapping对象。
注意：这些对象的信息都是通过反射的方式获取的。
对象信息包括：path：匹配路径
        type：对应的的要转发的具体的javaAciton类
        map：来保存调用成功或失败时要转发到的页面的路径信息。
在ActionServlet中定义一个Map，将path作为key值，actionMapping对象作为value值，进行匹配。
这样每次，我们就可以根据请求的path，来获取所有有关action调用和转发的信息了。

心得

空虚了就是该进步的时候了。技术的变化太多，进步太快，但是始终记得万变不离其宗。最原始的也许是最经典的。Struts的由来是各种前端框架的“宗”。
还是应该用心去再体会一下。