JAVA编程：深切全体剖析Spring MVC framework

在ruby里才是一切皆对象。当然我不并不是很了解ruby，但是ruby确实是将语法简化得很好。在现今的MVCframework里，仿佛Webwork2渐渐成为支流，Webwork2+SpringFramework的组合变得愈来愈盛行。这仿佛意味着Spring自带的MVCframework远比Webwork2差，以是人人纷繁用Webwork2来取代。的确，Spring的MVCframework不算是全部Spring的中心部件，但它的能力却凌驾了良多人的设想。良多人包含xiecc以为Spring的MVCframework长短常优异的，乃至比Webwork2更优异。

上面枚举一下Spring的MVCframework在计划时做出的一些主要的决意，并将之和相干的MVCframework如Webwork2或struts举行对照：

1、Spring的全部MVC设置是基于IOC容器的

与struts或webwork2比拟，这是一个ms有点奇异的决意，看一下SpringMVC的设置文件，开始看到的不是action大概form，而是一些有着特命名字的bean，Bean上面的设置是一些复杂或有点庞大的属性。我们看到的是呆板更简单的数据布局，而不是人更简单了解的元素。

可是这恰好是Spring的MVC壮大的本源！由于它的设置就是Spring的中心IOC容器的设置，这意味着一切IOC容器的能力都能够在这里展示，我们能够随心所欲地对SpringMVC举行扩大和加强，我们能够完成在别的MVCframwork中良多不可思议的义务。想扩大新的URL映照体例吗？要换一个themeResolver或LocalReolver的完成吗？想在页面中显现新范例的View（好比说RDF，呵呵，一个小奥密：xiecc是研讨语义网的，固然整天吊儿郎当，不写论文，只写八卦）？乃至想间接在Controller里界说AOP吗？这些对Spring的MVC来讲都是小菜一碟。

我没有细心研讨过Webwork2的扩大机制，我晓得经由过程Webwork2的interceptor机制，能够举行良多的扩大，乃至有一个复杂复杂的IOC容器。但不论它有多壮大，供应了几扩大点。它的能力都很难和真实的IOC容器比拟。而struts的plugin功效则是着名的滥，固然它也供应了plugin机制。

Spring接纳IOC设置的另外一个缘故原由是使Spring的MVC与Spring的IOC容器的整合变得十分的简单。Spring供应了与struts与webwork2的整合，可是如许整合都必要在举行直接的包装，感到总不是很天然。并且还会招致一个观点多个设置，webwork2就必要在Spring里设置bean，再设置本人的xwork文件。设想一下吧，我们的bean间接就是一个controller，间接能够完成MVC的一切义务，这是几爽的感到。

RodJohnson接纳IOC容器来完成的另外一个缘故原由是这会削减很多多少开辟事情量。看一下urlMapping吧，它供应的property自己就是一个HashMap，只要设置完成，我们的bean里的数据就天然存在了，哈哈，好爽吧。不必象struts那样剖析XML，再把它的内容一项一项地读到HashMap里。

固然如许的设置会有点奇异，但假设我们对Spring的IOC容器十分熟习的话，会发明它十分的亲热，也十分的复杂。

最初是一个复杂的小奥密，Spring怎样晓得某个bean的设置就是urlMapping？另外一个bean的设置就是viewResolver？实在很复杂，把一切的bean全体读到内存里，然后经由过程bean的名字或范例往找就好了。经由过程名字往找就是复杂的getBean办法，经由过程范例往找则利用了BeanFactoryUtils.beansOfTypeIncludingAncestors的静态办法。

2、Spring供应了明白的Model，View观点和响应的数据布局

在Spring里有一个风趣的数据范例叫做ModelAndView，它只是复杂地把要显现的数据和显现的了局封装在一个类里。可是它却供应了明白的MVC观点，特别是model观点的强化，使程序的逻辑变得更明晰了。

记得之前在Struts里写程序里的时分，为了显现数据常常本人把工具放到HttpSession或HttpServletRequest里（或set到form里，固然不太有效），这形成了model观点的含混，并且也招致了struts与JSP页面的紧耦合。假设我们要交换成Veloctiy，就得别的加一个plugin，由于在velocity里数据是不必要不放到request里的。

Webwork2里夸大的是与Webframework解耦和它的command形式的复杂性，因而在它的action里只要复杂的get或set办法，假设前往数据，也只是复杂地前往一个String.固然如许的完成有它的优点，可是它淡化了model和view的观点。RodJohnson以为Webwork2里的Action同时包括了Action和Model的职责，如许一个类的职责太多，不是一个很好的计划。固然JasonCarreira不太认同这类概念，由于Action里的model对象完成能够delege给别的对象。但不论如何，这类争辩的本源在于Webwork2里淡化了model，view乃至web的观点。仁者见仁，智者见智，最初的了局仍是看团体喜好好吧。

3、Spring的Controller是Singleton的，大概是线程不平安的

和Struts一样，Spring的Controller是Singleton的，这意味着每一个request过去，体系城市用原本的instance去向理，如许招致了两个了局：我们不必每次创立Controller，削减了对象创立和渣滓搜集的工夫；因为只要一个Controller的instance，当多个线程挪用它的时分，它内里的instance变量不是线程平安的。

这也是Webwork2吹捧的中央，它的每一个Action都是线程平安的。由于每过去一个request，它就创立一个Action对象。因为古代JDK渣滓搜集功效的效力已不成成绩，以是这类创立完一个对象就抛弃的形式也失掉了很多多少人的承认。RodJohnson乃至以此为例证实J2EE供应的objectpool功效是没多年夜代价的。

可是当人们在吹捧线程平安怎样怎样主要的时分，我想叨教有几人在几情形下必要思索线程平安？RodJohnson在剖析EJB的时分也提出过别的成绩，并非没有了EJB的线程平安邪术，天下就会死亡的，年夜多半情形下，我们基本不必要思索线程平安的成绩，也不思索objectpool.由于我们年夜多半情形下不必要坚持instance形态。

最少我写了那末多的strutsAction，写了那末多的SpringController，几近没有碰着必要在instance变量坚持形态的成绩。固然大概是我写的代码不敷多，Struts的计划者CraigR.McClanahan已经说事先他计划struts时有两个前提不成熟：事先没有测试驱动开辟的观点；事先JVM的渣滓搜集功能太次。假设如今从头计划的话，他也会接纳每一个request天生一个新对象的计划办法，如许能够办理失落线程平安的成绩了。

4、Spring不象Webwork2或tapestry那样往埋没Servlet相干的元素如HttpServletRequest或HttpServletResponse

这又是一个主要的计划决意。在Webwork2里我们没有HttpServletRequest大概HttpServletResponse，只要getter，setter或ActionContext里数据，如许的了局招致一个洁净的Action，一个与Web完整有关的Action，一个能够在任何情况下自力运转的bean.那末Webwork2的如许一个基于Command形式的Action事实给我们带来了甚么？我想次要有两点：

1、它使我们的Action能够十分简单地被测试。

2、用户能够在Action里增加营业逻辑，并被别的类重用。

但是细心跟Spring对照一下，我们就会发明这两点功效所带来的优点实在其实不象我们设想的那末明显。Spring的Controller类也能够十分轻松被测试，看一下spring-mock上面的包吧，它供应的MockHttpServletRequest，MockHttpServletResponse另有别的一些类让测试Controller变得非常轻松。再看一下Action里的营业逻辑吧，JasonCarreira已经说我们能够恣意地在Webwork2的Action里加营业逻辑，由于Action是不依附于Web的。可是有几人真正往Action里加营业逻辑的？年夜多半人城市营业逻辑delegate给另外一个Service类或Manager类。由于我们很分明，往Action里加营业逻辑会使全部系统的分层架构变得不明晰，不论如何，Web层就是Web层，营业层就是营业层，二者的逻辑混在一同总会带来成绩的。并且往Action里加营业逻辑会利用这个Action类变得复杂，Webwork2的Action是每一个request都创立实例的，只管带来的功能影响不太年夜，但其实不暗示每次都要把营业逻辑再new出来，营业逻辑在年夜多半的情形下应当是单例的。

不把request和response展示给用户固然还会带来功效上的丧失，大概一样平常的场所，用用webwork2供应的接口已充足了，但偶然我们必需要晓得request和response才干发扬出更年夜的能力。好比我之前的一个项目里有一个经由过程递回静态天生的树状布局的页面，在jsp页面上显现递回是疾苦或不成能的，因而我用response间接write出页面，这在spring里很easy，但在webwork里大概对照难了（偶不敢一定，偶研讨得不敷深，大概妙手是有举措的）。

5、Spring供应了不错但不敷充实的interceptor机制

转头看一下struts，它在架构里乃至没有给我们供应hookpoint的时机，我们没有任何时机到场本人的interceptor.我们只能经由过程重载struts的RequestProcessor类来举行一点无限的扩大。

到了Webwork2，仿佛interceptor一会儿成了全部Framework的中心，除Action的中心部件，别的一切的工具都是interceptor.它的超强的interceptor功效使们扩大全部架构变得十分便利。有人称这类interceptor为AOP，JasonCarreira则自大地传播鼓吹这个叫做pragamticAOP.我不认同这是AOP，它只是复杂的interceptor机制。但不论怎样，它的interceptor的确有壮大的功效。

Spring也供应了它的interceptor机制，它的HandlerInterceptor三个interceptor办法：peHandle，postHandle，afterCompletion.分离对应Controller实行前，Controller实行后和pagerender以后。固然年夜多半情形下已够用，可是从功效下去说明显它没有Webwork2壮大。从AOP的角度来看，它没有供应aroundinterceptor，而只要before与afterinterceptor.这意味着我们没法在interceptor前后坚持形态，最复杂的情形假设我们要盘算一个Controller的实行工夫，我们必需在实行完before后把begintime这个形态坚持住，再在after里把它修改来，可是明显这个形态坚持会是个成绩，我们不克不及把它放到instance变量里，由于interceptor不是线程平安的。大概经由过程ThreadLocal能够办理这个成绩，可是云云复杂的功效要用到如许的办法来处置，明显这个Interceptor自己计划上仍是有点成绩的。

6、Spring供应了MultiActionController，使它能够在一个类里包括多个Action

这个计划和struts的DispatchAction有点相似，只不外供应了更天真的机制。当我们的项目变年夜的时分，把功效相似的办法放到统一个Action里完整值得的！Webwork2短少如许的机制。假设看一下Spring的源代码，会发明实在完成MultiActionController的事情量相称的少，只不外是用反射机制把剖析出来的办法名实行一下就完事了。实在Webwork2也完整能够供应如许的机制。固然从计划下去说的确不是很文雅，可是它的确很有效。

7、Spring供应了更多的选择体例

看看Spring里供应的Controller吧，它供应了很多多少分歧的Controller类。要天生Wizard吗？要专门用于提交form的Controller吗？要执多个办法的类吗？Spring供应了丰厚的子类来扩大这些选择。固然我们还能够很轻松地本人扩大这些功效。

再看看Spring的ViewResolver吧，它供应了有数分歧范例的ViewResolver.更主要的是我们自界说我们的页面映照体例。看看strtus，看看webwork2，城市存在页面与forwardname的一层直接转换，我们必需在设置文件里设置好某个字符串（典范的是success）对应的是谁人页面。可是Spring里我们有了更年夜的自在度，我们能够接纳webwork2的战略，也能够接纳更复杂的战略，如将JSP文件名往失落扩大名的映照办法。大概有人以为这类映照体例很稚嫩，可是我以为它长短常有效的体例，即便在年夜项目里。

另有新的扩大吗？看看SpringWebFlow吧，它是SpringFramework的子项目。它为一长串的基于页面流的Wizard页面供应了可设置的完成体例。在Spring1.3里，它将是SpringFramework的一部分。

8、Spring的tag

只管Spring的tag数目上少得不幸，但它倒是经心计划的。它的方针很复杂：让美工能够轻松地编纂页面。由于在Spring的页面里Text仍旧是Text，checkbox仍旧是CheckBox，而不象在struts或webwork2中的Tag.它只是用Springbind对输出内容举行了一下包装。以是只管页面显现代码上会比Webwork2多，但这相对是有代价的。

在接上去的几章里，我会剖析一下Spring是怎样让我们的Web使用不必要晓得ApplicationContext就可以够会见IOC容器的，然后会对Spring的计划和实行历程举行复杂的源码剖析，然后给出几个扩大SpringMVC的办法。
再说说缺点：首先java功能强大的背后是其复杂性，就拿web来说，当今流行的框架有很多，什么struts，spring，jQuery等等，而这无疑增加了java的复杂性。

你就该学一学Servlet了。Servlet就是服务器端小程序，他负责生成发送给客户端的HTML文件。JSP在执行时，也是先转换成Servlet再运行的。虽说JSP理论上可以完全取代Servlet，这也是SUN推出JSP的本意，可是Servlet用来控制流程跳转还是挺方便的，也令程序更清晰。接下来你应该学习一下Javabean了，可能你早就看不管JSP在HTML中嵌Java代码的混乱方式了，这种方式跟ASP又有什么区别呢？

Java 不同于一般的编译执行计算机语言和解释执行计算机语言。它首先将源代码编译成二进制字节码（bytecode），然后依赖各种不同平台上的虚拟机来解释执行字节码。从而实现了“一次编译、到处执行”的跨平台特性。

你快去找一份Java的编程工作来做吧（如果是在校学生可以去做兼职啊），在实践中提高自己，那才是最快的。不过你得祈祷在公司里碰到一个高手，而且他 还愿意不厌其烦地教你，这样好象有点难哦！还有一个办法就是读开放源码的程序了。我们知道开放源码大都出自高手，他们设计合理，考虑周到，再加上有广大的程序员参与，代码的价值自然是字字珠叽，铿锵有力（对不起，偶最近《金装四大才子》看多了）。

是一种使网页(Web Page)由静态(Static)转变为动态(Dynamic)的语言

至于JDBC，就不用我多说了，你如果用java编过存取数据库的程序，就应该很熟悉。还有，如果你要用Java编发送电子邮件的程序，你就得看看Javamail 了。

Java语言支持Internet应用的开发，在基本的Java应用编程接口中有一个网络应用编程接口（java net），它提供了用于网络应用编程的类库，包括URL、URLConnection、Socket、ServerSocket等。Java的RMI（远程方法激活）机制也是开发分布式应用的重要手段。

如果你学过HTML，那么事情要好办的多，如果没有，那你快去补一补HTML基础吧。其实JSP中的Java语法也不多，它更象一个脚本语言，有点象ASP。

至于JDBC，就不用我多说了，你如果用java编过存取数据库的程序，就应该很熟悉。还有，如果你要用Java编发送电子邮件的程序，你就得看看Javamail 了。

有时间再研究一下MVC结构（把Model-View-Control分离开的设计思想）

Pet Store.（宠物店）是SUN公司为了演示其J2EE编程规范而推出的开放源码的程序，应该很具有权威性，想学J2EE和EJB的朋友不要 错过了。