对于Struts和Spring两种MVC框架的比较

2 Struts框架
    Struts是Apache软件基金Jakarta项目的一部分。Struts框架的主要架构设计和开发者是Craig R．McClanahan。Struts是目前Java Web MVC框架中不争的王者。经过长达五年的发展，Struts已逐渐成长为一个稳定、成熟的框架，并占有MVC框架最大的市场份额。但Struts某些技术特性已经落后于新兴的MVC框架。面对Spring MVC，Webwork2这些设计更精密，扩展性更强的框架，Struts受到了前所未有的挑战。但就产品开发的角度，Struts仍然是最稳妥的选择。
    Struts由一组相互协作的类(组件)，Serlvet以及jsp tag lib组成。基于Stmts构架的Web应用程序基本上符合JSPModel2的设计标准，是MVC设计模式的一种变化类型。根据对framework的描述，很容易理解为什么说Struts是一个Web framwork，而不仅仅是一些标记库的组合。但Struts也包含了丰富的标记库和独立于该框架工作的实用程序类。Struts有其自己的控制器(Controller)，同时整合了其他的一些技术去实现模型层(Model)和视图层(View)。在模型层，Struts可以很容易的与数据访问技术相结合，包括EJB，JDBC和Obiect Relation Bridge。在视图层，Struts能够与JSP，VelocityTemplares,XSL等等这些表示层组件相结合。
    Struts的体系结构，Struts framework是MVC模式的体现，分别从模型、视图、控制描述struts的体系结构(Architec-ture)。
    (1)从视图角度(View)主要由JSP建立，Struts自身包含了一组可扩展的自定义标签库(TagLib)，可简化创建用户界面的过程。目前包括：Bean Tags，HTML Tags，Logic Tags，Nested Tags，Template Tags这几个Taglib。有关其详细资料请参考Struts用户手册。
    (2)从模型角度(Model) 模型主要是表示一个系统的状态(有时候，改变系统状态的业务逻辑操作也划分到模型中)。在Struts中，系统的状态主要有ActiomForm Bean体现，一般情况下，这些状态是非持久性的。如果需要将这些状态转化为持久性数据存储，Struts本身也提供了Utitle包，可以方便与数据库操作。
    (3)从控制器角度(Controller) 在Struts framework中，Controller主要是ActionServlet，但是对于业务逻辑的操作则主要由Action，ActionMapping，ActionForward这几个组件协调完成(也许这几个组件，应该划分到模型中的业务逻辑一块)。其中，Action扮演了真正的业务逻辑的实现者，而ActionMapping和ActionForward则指定了不同业务逻辑或流程的运行方向。
    对于Struts如何控制、处理客户请求，通过对Struts的4个核心组件介绍来具体说明。这几个组件是：ActionServlet；Action Classes；Action Mapping(此处包括ActionForward)；ActionFrom Bean。

3 Spring框架
    Spring实际上是《Expert One—on—One J2EE Design andDevelopment》一书中所阐述的设计思想的具体实现。在One—on一One一书中，Rod Johnson倡导J2EE实用主义的设计思想，并随书提供了一个初步的开发框架实现(interface2l开发包)。而Spring正是这一思想的更全面和具体的体现。RodJohnson在interface21开发包的基础之上，做了进一步的改造和扩充，使其发展为一个更加开放、清晰、全面、高效的开发框架。
    Spring是一个开源框架，由Rod Johnson创建并且在其著作《J2EE设计开发编程指南》里进行了描述。它是为了解决企业应用开发的复杂性而创建。Spring使用基本的JavaBeans完成以前只可能由EJB完成的事情变得可能。然而，Spring的用途不仅限于服务器端的开发。从简单性、可测试性和松耦合的角度，任何Java应用都可以从Spting中受益。Spring是一个轻量的控制反转和面向切面的容器框架。这些描述过于简单。但的确概括出Spring。
    (1)轻量从大小与开销而言Spting都是轻量的。完整的Spring框架可在一个大小1 MB多的JAR文件里发布。并且Spring所需的处理开销也是微不足道。此外，Spring是非侵入式的：典型地，Spring应用中的对象不依赖于轻量。
    (2)控制反转 Spring通过一种称作控制反转(IoC)的技术促进了松耦合。当应用了IoC，对象被动地传递它们的依赖而不是自己创建或者查找依赖对象。可以认为IoC与JNDI相反，不是对象从容器中查找依赖，而是容器在对象初始化时不等被请求就将依赖传递给它。
    (3)面向切面Spring包含对面向切面编程的丰富支持，允许通过分离应用的业务逻辑与系统服务(例如审计与事物管理)进行内聚性的开发。应用对象只做它们应该做的，完成业务逻辑，仅此而已。并不负责(甚至是意识)其它的系统关注点，例如日志或事物支持。
    (4)容器 Spring包含和管理应用对象的配置和生命周期，在此意义上它是一种容器。可以配置每个bean如何被创建，基于一个配置原形为bean创建一个单独的实例或每次需要时都生成一个新的实例以及它们是如何相互关联的。然而，Spring不应该被混同于传统重量的EJB容器，它们经常是庞大与笨重的，难以使用。
    (5)框架Spring使由简单的组件配置和组合复杂的应用成为可能。在Spring中，应用对象被声明式地组合，典型地是在一个XML文件里，Spr4ng提供了很多基础功能(事务管理、持久性框架集成等等)，并留有应用逻辑开发。
    例如：Spring有3个重点，一个是面向接口编程：一个是控制反转；另外一个就是依赖注入。有了控制反转就有了声明性的bean，在application．xml也就是Spring的核心配置文件里面声明bean的属性，对应的类，引用名称，这些是为编码时要用到的bean做准备的，对应web应用程序，Spring有专门的类SpringContextLoader，等等。另外在web．xml里可以用context-param子节点将application．xml纳入范围，这样容器在加载web应用时，就将对应的bean加载了，剩下的是如何引用这些bean的问题，这里用到Spring的接口注入，也是spring用的最多的依赖注入方式。例如：这有两个类，一个是Main．java，一个是Demo．java．这里Main里面用到了Demo；

    注意看到Main里面需要用到Demo的实例，因此，需要硬编码，即静态绑定(在编译期间就需要绑定)，这绝对会增大后期维护工作量，至少每次扩展或者修改类以后需要重新编译已存在的iavabean组件。
    Spring的依赖注入有机会实现动态绑定，原理很简单，用到了接口，接口是不能生成实例的，再加上iava的多态，接口可指向它的实现类。

    所以试着为bean添加一个接口

}
    注意看加重部分，用Spring提供的两个类，BeanFactory，和xmhxxxxx，直接读取配置文件。然后用getBean(id)；取得bean，这个时候返回的对象是范型，比如Object obj=beanFac-tory．getBean(demo)；将改后的写在下面，但没测试过。
    这样就解耦了，实现无侵入式。不要忘记要将需要的bean在配置文件里面声明。
    所有Spring这些特征使编写更干净、更易管理、并且更易于测试的代码。也为Spring中的各种子框架提供了基础。

4 结语
    人们日益对开源框架的重视．使得很多项目的成本大大降低，并且投放使用以及维护速度都增加了。现在的开源框架都有很高的质量，提供了很好的文档，一些书籍让开发者做参考。即便如此，两大因素使得J2EE领域充满了不确定性：开源领域和J2EE“标准”的冲突和AOP的日益重要。
    开源和标准之间的冲突表现在两个方面。一个是表现层，JSF的身后有Sun公司和其他的一些大公司，而在这个领域有Struts等开源产品与之竞争。在中间层，EJB3．0采用J2SE5．0的annotations实现了依赖注入(dependency iniection)的功能，但这个功能只是Spring的一个子集。
    在这两个领域，开源产品都更加革新。JSP借鉴了ASP．NET，而Tapestry则采用了WebObjects的思想。
同样的，不知道EJB3．0为何要尝试着标准化依赖注入，即使这样会使之不可避免地丧失很多功能。EJB 3．0也要进入程序编写领域，而J2EE规范在这方面还没有涉足。
    于此同时，AOP的重要性在J2EE社区猛增，在使用上，AOP也越来越受到开发者的青睐。像Spring、dynaop等被称作“带着双拐的AOP”实现，提升了AOP的知名度。而纯粹的AOP技术比如AspectJ，在将来的几年也会流行起来。
    其次，JBoss通过JCP和EJB3．0保持一致，它极大地推动了AOP技术。但即使如此，JCP还没有转向AOP迹象。
    下一代的J2EE规范将拥抱更简单的POJ0编程模型，就像Spring和Hibermate做的一样。J2EE开发者也注定要从“欺诈客户”转到以自己的编程经验开发。这次改变将受到大多数人的欢迎，不像以前那样每一个新规范发布后，最终都没有能很好的实现。