struts框架具有组件的模块化，灵活性和重用性的优点，同时简化了基于MVC的web应用程序的开发。
优点：
Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。
除此之外，Struts的优点主要集中体现在两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。
关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。
另外，struts是业界"标准"（很多成功案例），学习资源丰富，HTML标签非常优秀
缺点：
Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。
Struts将MVC的Controller一分为三，在获得结构更加清晰的同时，也增加了系统的复杂度。
ActionForms使用不便、无法进行单元测试（StrutsTestCase只能用于集成）
具体来讲,
Struts的优点有:
2．Hibernate
Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。
Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序实用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任。
大多数开发机构经常采取创建各自独立的数据持久层。一旦底层的数据结构发生改变，那么修改应用的其余部分使之适应这种改变的代价将是十分巨大的。Hibernate适时的填补了这一空白，它为Java应用提供了一个易用的、高效率的对象关系映射框架。hibernate是个轻量级的持久性框架，功能却非常丰富。
优点：
a.Hibernate 使用 Java 反射机制 而不是字节码增强程序来实现透明性。
b.Hibernate 的性能非常好，因为它是个轻量级框架。 映射的灵活性很出色。
c.它支持各种关系数据库，从一对一到多对多的各种复杂关系。
缺点：它限制您所使用的对象模型。(例如，一个持久性类不能映射到多个表)其独有的界面和可怜的市场份额也让人不安，尽管如此，Hibernate 还是以其强大的发展动力减轻了这些风险。其他的开源持久性框架也有一些，不过都没有 Hibernate 这样有市场冲击力。
上面回贴情绪有点激动，希望谅解，我不是因为有人批评Hibernate而感到不快，而是因为帖子里面的观点实在让我觉得荒谬。不管觉得Hibernate好也吧，不好也吧，我唯一觉得遗憾的是，在中文论坛里面找不到一个对Hibernate的真正高水平的评价。在TSS上有一个关于Hibernate的hot thread，跟了几百贴，其中包括Hibernate作者Gavin和LiDO JDO的CTO，对于JDO和Hibernate有过一些激烈的争论，我曾经耐心的看了一遍，仍然没有发现针对Hibernate真正有力的攻击，那些所谓的攻击无非针对Hibernate没有一个GUI的配置工具，没有商业公司支持，没有标准化等等这些站不住脚的理由。
补充几点我的意见：
一、Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合，例如Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。从这个意义上来说，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。
二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。
三、Hibernate不能用来直接和Entity Bean做对比，只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构：
传统的架构：
1) Session Bean <-> Entity Bean <-> DB
为了解决性能障碍的替代架构：
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提高上面架构的开发效率的架构：
3) Session Bean <-> DAO <-> Hibernate <-> DB
就上面3个架构来分析：
1、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。
2、运行效率：如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。
3、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。
4、分布式，安全检查，集群，负载均衡的支持
由于有SB做为Facade，3个架构没有区别。
四、EB和Hibernate学习难度在哪里？
EB的难度在哪里？不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题，需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。
Hibernate难在哪里？不在Hibernate本身的复杂，实际上Hibernate非常的简单，难在Hibernate太灵活了。
当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么可以选择的余地，所以你根本就不用花费精力去设计方案，去平衡方案的好坏，去费脑筋考虑选择哪个方案，因为只有唯一的方案摆在你面前，你只能这么做，没得选择。
Hibernate相反，它太灵活了，相同的问题，你至少可以设计出十几种方案来解决，所以特别的犯难，究竟用这个，还是用那个呢？这些方案之间到底有什么区别呢？他们的运行原理有什么不同？运行效率哪个比较好？光是主键生成，就有七八种方案供你选择，你为难不为难？集合属性可以用Set，可以用List，还可以用Bag，到底哪个效率高，你为难不为难？查询可以用iterator，可以用list，哪个好，有什么区别？你为难不为难？复合主键你可以直接在hbm里面配置，也可以自定义CustomerType，哪种比较好些？你为难不为难？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么情况下用哪种方案比较好，你为难不为难？
这个列表可以一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会觉得幸福呢？还是悲哀呢？如果你是一个负责的程序员，那么你一定会仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会觉得你已经陷入进去拔不出来了。如果是用EB，你第一秒种就已经做出了决定，根本没得选择，比如说集合属性，你只能用Collection，如果是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。
3．
它是一个开源的项目，而且目前非常活跃；它基于IoC（Inversion of Control，反向控制）和AOP的构架多层j2ee系统的框架，但它不强迫你必须在每一层 中必须使用Spring，因为它模块化的很好，允许你根据自己的需要选择使用它的某一个模块；它实现了很优雅的MVC，对不同的数据访问技术提供了统一的 接口，采用IoC使得可以很容易的实现bean的装配，提供了简洁的AOP并据此实现Transcation Managment，等等
优点：
a. Spring能有效地组织你的中间层对象，不管你是否选择使用了EJB。如果你仅仅使用了Struts或其他为J2EE的 API特制的framework，Spring致力于解决剩下的问题。
b. Spring能消除在许多工程中常见的对Singleton的过多使用。根据我的经验，这是一个很大的问题，它降低了系统的可测试性和面向对象的程度。
c. 通过一种在不同应用程序和项目间一致的方法来处理配置文件，Spring能消除各种各样自定义格式的属性文件的需要。曾经对某个类要寻找的是哪个魔法般的属性项或系统属性感到不解，为此不得不去读Javadoc甚至源编码？有了Spring，你仅仅需要看看类的JavaBean属性。Inversion of Control的使用（在下面讨论）帮助完成了这种简化。
d.通过把对接口编程而不是对类编程的代价几乎减少到没有，Spring能够促进养成好的编程习惯。
e. Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs。在Spring应用中的大多数业务对象没有依赖于Spring。
f. 使用Spring构建的应用程序易于单元测试。
g. Spring能使EJB的使用成为一个实现选择,而不是应用架构的必然选择。你能选择用POJOs或local EJBs来实现业务接口，却不会影响调用代码。
h. Spring帮助你解决许多问题而无需使用EJB。Spring能提供一种EJB的替换物，它们适用于许多web应用。例如，Spring能使用AOP提供声明性事务管理而不通过EJB容器，如果你仅仅需要与单个数据库打交道，甚至不需要一个JTA实现。
i. Spring为数据存取提供了一个一致的框架,不论是使用的是JDBC还是O/R mapping产品（如Hibernate）。
Spring确实使你能通过最简单可行的解决办法来解决你的问题。而这是有有很大价值的。
缺点：使用人数不多、jsp中要写很多代码、控制器过于灵活，缺少一个公用控制器
//
今年我一直在思考web开发里的前后端分离的问题，到了现在也颇有点心得了，随着这个问题的深入，再加以现在公司很多web项目的控制层的技术框架由struts2迁移到springMVC，我突然有了一个新的疑问无法得到正确的解释，为什么我们现在做java的web开发，会选择struts2或者springMVC这样的框架，而不是使用servlet加jsp这样的技术呢？特别是现在我们web的前端页面都是使用velocity这样的模板语言进行开发，抛弃了jsp，这样的选择又会给我们java的web开发带来什么样的好处，延着这个问题的思路，我又发现新的疑问，为什么现在很多java企业级开发都会去选择spring框架，spring框架给我们开发的应用带来了什么？这么一想还真是问倒我了，我似乎很难找到一串能让人完全信服的答案，最终我发现，这些我认为我很熟悉很常用的技术，其实还有很多让我陌生不解的地方，这些陌生和不解的地方也正是我是否能更高层次使用它们的关键，今天这篇文章我就来讲讲这些问题，不过struts2，spring这样的技术经过这么多年的积累已经是相当庞大和复杂，它们的面很广，本人虽然已经用了它们多年，还是有很多技术不熟悉和不清楚，所以本文不是全面对我题目做出解答的文章，而是根据我现有知识结构来理解这个问题。
软件里有很多优秀的框架，有一种类型的框架，它的特点是建立在一个现有技术的基础上，提供和现有技术一样业务功能的技术框架，这个新的技术框架比原技术更加易用，更加健壮同时功能更加强大，例如：jQuery，以及本文所要谈到的struts2和springMVC，深究这些框架都是相当之复杂，但是它们的优点其实只有一个：就是让使用者只关心核心业务的开发，框架帮你屏蔽原有技术跟业务开发无关的各类技术问题。像jQuery，struts2或springMVC这类框架之所以优秀，就是它们在这点上做的太好了，以至于很多使用它的程序员都已经不清楚原有技术的真实面目，因此我们要将struts2理解的更好，使用的更加熟练和深入，这里我们就要跳出struts2的技术，到struts2技术的源头servlet，仔细研究下servlet的特点，只有这样我们才能把struts2框架学的更好。
Servlet的作用是接收浏览器传给服务端的请求（request），并将服务端处理完的响应（response）返回给用户的浏览器，浏览器和服务端之间通过http协议进行沟通，其过程是浏览器根据用户的选择将相关信息按http协议报文的规范组装请求的http报文，报文通过网络传输到指定的服务器，服务器通过特定的web容器接收这个报文信息，例如：tomcat，jetty，jboss这样的web容器，web容器会将http报文解析出来，如果是用户请求，最终解析出来的报文信息会用一个request对象存储起来，服务端使用这个request做完相应的处理后，服务端程序将结果信息封装到response对象里，然后将response对象交给web容器，web容器则把这个response对象转变为http协议的报文，并将报文回传给浏览器，浏览器最后解析这个响应报文，将最终结果展示给用户。
Web容器创造了servlet接口，servlet接口就是开发人员自己实现业务逻辑的地方，程序员开发servlet就好比做填空题，而填空题的语境或者说上下文提示就是由request和response对象，但是javaEE规范里的servlet接口很简单，就三个方法init，service和destory，但是这个接口太笼统，所以规范里还提供了一个HttpServlet类，这个类根据http请求类型提供了doGet，doPost等方法，servlet接口最大的特点就是根据http协议的特点进行定义，因此做servlet开发时候如果使用者对http协议特点不是特别熟悉，都会碰到或多或少令人迷惑的问题，特别是碰到一些复杂特殊的请求时候：例如文件上传，返回特殊的文件格式到浏览器，这时候使用servlet开发就不是很方便了，servlet开发还有个问题可能大家常常被忽视，就是请求的数据的类型转化，http协议传输都是文本形式，到了web容器解析后也是文本类型，如果碰到货币，数字，日期这样的类型需要我们根据实际情况进行转化，如果页面传送的信息非常多，我们就不得不做大量类型转化，这种工作没有什么技术含量，是个体力活而且很容易导致程序错误。同时java的企业开发都是围绕javabean进行，类型转化好的数据还要封装到对应的javabean里，这种转来转去的事情对于项目开发绝对不是什么好事情，所以古老的struts1为这种问题找到了一种解决方案，就是定义了一个DTO对象（数据传输对象），专门负责做这样的事情，不过到了struts2，整个替代servlet的action本身就是一个javabean。
Java的企业开发一个技术特点就是使用javabean进行的，struts2的特点之一就是它替代servlet的操作类就是一个典型的javabean，首先struts2框架将页面传输的数据进行类型转化和封装后将请求信息封装到了这个javabean的属性里，这样我们开发web程序时候就省去了烦心的类型转化和封装的问题，前面我讲到传统的servlet是根据http协议进行定义的，它会按你请求方式（post还是get方式）来处理用户的请求，但是对于一名程序开发人员而言，一个请求，具体到一个url，其实对于服务端而言就是服务端对外提供的一个功能，或者说是服务端对外的一个动作，如果我们使用servlet开发程序我们就得把http的动作转化为具体的业务动作，这就让程序开发变得繁琐，增强了开发的难度，所以struts2替代servlet的javabean就屏蔽了servlet里http的请求方式和具体业务动作转化的问题，javabean里的每一个方法都可以和每一个url请求一一对应，这必然减轻了开发的难度问题。
Servlet另一个作用就是构造response对象，让页面获得正确的响应，其实现代的浏览器是一个多媒体工具，文字，图片，视屏等等东西都可以在浏览器里显示，资源的不同就会导致http响应报文的差别，如果我们使用servlet开发就要根据资源的不同在java程序里用硬编码的形式处理，这样的程序很难复用，而且如果程序员对某种资源的处理理解不到位，就会导致问题的出现，struts2通过配置文件的形式将这样的逻辑从java程序里剥离出来，使用配置的方式进行统一管理，这个做法和spring的AOP方式类似，这样就让结果处理方式更加统一，更加利于管理，同时也提升了程序的健壮性以及降低了开发的难度。
Servlet在MVC开发模式里就是其中C层即控制层，控制层就像俄罗斯的双头鹰（一个头向东看一个头向西看）一样，一个头向M层模型层看，一个头向V层视图层看，模型层也是用java编写的，控制层也属于服务端语言开发，所以M层和C层的沟通没有天然的障碍，但是和V层视图层就不一样了，这是一个跨语言的沟通，对于浏览器，它只懂得html，javascript和css，浏览器是理解不了java这种语言的东西，但是要让服务端的东西能被浏览器理解接受，我们就必须得把服务端的响应信息放到页面里，因此就需要一个技术把java的信息转化到html页面里，这就是javaEE规范里提供了jsp技术，jsp其实是一种服务端技术而非客户端技术，不过它看起来似乎更像html技术，最早的jsp开发里都是直接将java代码写到页面里，这种坏处谁都知道，之后javaEE规范提供了自定义标签技术，使用一种类似html标签的方式来解析java代码，struts2框架提供了一整套完整的自定义标签技术，这似乎听起来不算啥，但是它的作用非凡，因为自定义标签之所以叫自定义就是每个人都可以自己来定义，如果没有一个规范必然产生混乱，而且一套完善的自定义标签是个系统工程，一套完整的自定义标签相当于我们在自己定义一套新的开发语言，做程序的人听到这个一定就会明白开发一套完整的自定义标签的工作量和开发难度都是难以想象的，而且自定义标签都是和控制层紧密相连，其难度又会增加一个维度，所以struts2提供的自定义标签对于业务开发带来的将是质的飞越。
Servlet里还有两个重要的技术：监听器和过滤器，对于监听器在web开发里使用的场景比较少，都是一些十分特别的情况才会使用，大部分web开发里可以忽略它的使用，我们用的最多的监听器可能就是对ServletContext创建和销毁的监听器，ServletContext是整个web应用的全局对象，它和Web应用的生命周期绑定在一起，因此使用这个监听器对Web应用的全局信息进行初始化和销毁操作，例如spring容器的初始化操作。比较有意思的是过滤器，在struts2里有个拦截器，它们的作用相同都是用来拦截请求的，因为拦截器是struts2的特有功能，在struts2里使用拦截器自然比使用过滤器更顺手，其实拦截器所用的技术比过滤器更加先进，因为拦截器使用了反射技术，因此拦截器拦截的面更大，控制请求的能力更强，它能完成的任务也会更加的丰富多彩。
在我第一次接触struts2时候，有人告诉我struts设计的一个目的就是想屏蔽在控制层里操作request和response对象，因为这两个http协议的儿子会造成web开发里思路的混乱，但是我在实际开发里却经常不自觉的使用这两个对象。而且本人做前端开发非常喜欢使用ajax，使用ajax技术时候我就很讨厌struts2的自定义标签，我更加喜欢在页面里用javascript技术处理各种信息，最终struts2在我眼里就是一个servlet的变体，因此曾经有段时间我常常在想是不是可以抛弃struts2，直接用servlet，因为struts2里用到了太多反射机制，特别是使用注解做配置（注解是用反射实现的），在java里反射的执行效率是非常低的，直接使用servlet一定能提升web应用的执行效率。其实这个倒很难做到，因为当时我没法在servlet里灵活的运用spring技术。
下面我要谈谈spring了。
spring技术可以说是java企业开发里最重要的技术，不过真的理解spring的作用和意义还真是一件麻烦的事情，很多人对spring理解其实都是停留在使用阶段（例如：声明式事务很好用等等），当今的spring技术生态环境里可谓是蔚为壮观，spring已经包罗万象，它的内容之多完全不亚于它的本源java语言了，而spring这么大的框都是建立在ioc和aop技术之上，只有深入理解了这两个技术我们才能明白为什么spring这个框能装的下那么多东西了。
首先是ioc，ioc技术第一个解释叫做控制反转，它还有个解释就是依赖注入，这两个名字很难从字面理解，但是当你理解它的原理后就会发现它们的描述是何等准确。Ioc技术的本质就是构建对象的技术换句话说就是将一个类实例化成对象的技术，在java里实例化类通过new关键字进行的，每次new一个类都会产生一个新的实例对象，这么做视乎很浪费，有时这种浪费还挺危险，因为在程序开发时候我们常常只需要某个类永远只能产生一个的实例对象这个时候就得使用单例模式，此外在设计模式里还可以通过工厂方式产生对象，使用过spring的人看到上面的文字就知道了，spring里bean的定义就和上面的内容一一对应，scope属性single产生单例对象，prototype产生新对象，bean还可以通过工厂方式产生对象，可以说spring的bean就是制造对象的工具。面向对象编程里对象相当于显示生活中的一个实体，例如我们有个对象作用是完成打猎的操作，那么打猎这个对象内部包含两个辅助对象：人和枪，只有人和枪赋予了打猎这个对象，那么打猎对象才能完成打猎的操作，但是构建一个人和枪的对象并不是看起来那么简单，这里以枪为例，要创造一把枪我们需要金属，需要机床，需要子弹，而机床和子弹又是两个新对象，这些对象一个个相互嵌套相互关联，大伙试想下如果我们在java代码里构建一个枪的对象那是何其的复杂，假如我们要构造的不是简单的枪对象而是更加复杂的航空母舰，那么构造这个对象的成本之高是让人难以想象的，怎么来消除这种对象相互嵌套相互依赖的关系了？spring提供了一种方式，这种方式就是spring提供一个容器，我们在xml文件里定义各个对象的依赖关系，由容器完成对象的构建，当我们java代码里需要使用某个实例的时候就可以从容器里获取，那么对象的构建操作就被spring容器接管，所以它被称为控制反转，控制反转的意思就是本来属于java程序里构建对象的功能交由容器接管，依赖注入就是当程序要使用某个对象时候，容器会把它注入到程序里，这就叫做依赖注入。在java开发里我们想使用某个类提供的功能，有两种方式，一种就是构造一个新的类，新的类继承该类，另一种方式则是将某个类定义在新类里，那么两个类之间就建立一种关联关系，spring的ioc容器就是实现了这种关联关系（记住不是继承关系哦），那么某个类要被赋予到新类有哪些办法了？一般只有两种：一种就是通过构造函数，一种就是通过setXXX方式，这也是spring容器使用到了两种标准的注入方式。
不管是上面说的继承方式，还是关联方式其实都是增强目标对象能力的开发手段，在设计模式里有一种代理模式，代理模式将继承模式和关联模式结合在一起使用，代理模式就是继承模式和关联模式的综合体，不过这个综合体的作用倒不是解决对象注入的问题，而是为具体操作对象找到一个保姆或者是秘书，这就和小说里的二号首长一样，这个二号首长对外代表了具体的实例对象，实例对象的入口和出口都是通过这个二号首长，因为具体的实例对象是一号首长，一号首长是要干大事的，所以一些事务性，重复性的工作例如泡茶，安排车子，这样的工作是不用劳烦一号首长的大驾，而是二号首长帮忙解决的，这就是aop的思想，aop解决程序开发里事务性，和核心业务无关的问题，但这些问题对于业务场景的实现是很有必要的，在实际开发里aop也是节省代码的一种方式。
Spring的核心技术的作用本质就是一个 沟通机制，spring总是尽全力的让沟通的双方信息畅通，同时降低双方的沟通成本，在现实机构里一个善于沟通的人肯定是该公司的领导，很会沟通的领导能调动起各种资源的积极性，善于沟通的领导就会做到海纳百川，让各种不同人追随他，所以当今的spring就是一个大框，什么都可以往里装。
Spring很像银行，它不能直接创造物质财富，但是一切资源都要通过它进行流通，它能控制经济发展的走向，回到程序的世界，spring的作用是被标榜为程序之间的解耦，spring能降低不同模块之间的耦合度，原因就是在程序开发里不同模块之间信息的沟通是通过对象传递完成的，而对象能否顺利传递就是要合理的构建好对象，而管理好对象的构建方式就能管理好对象传递，这就是spring给系统架构设计带来的好处。
扫一扫
3727
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
