Struts和Hibernate和Spring的优缺点

引用自：http://www.busfly.cn/csdn/post/587.html

 

1.Struts

struts框架具有组件的模块化，灵活性和重用性的优点，同时简化了基于MVC的web应用程序的开发。

优点：
Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。
除 此之外，Struts的优点主要集中体现在两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提高开发效率。另 外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。
关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。

另外，struts是业界"标准"（很多成功案例），学习资源丰富，HTML标签非常优秀

缺点：
Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。
Struts将MVC的Controller一分为三，在获得结构更加清晰的同时，也增加了系统的复杂度。
ActionForms使用不便、无法进行单元测试（StrutsTestCase只能用于集成）

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 这样有市场冲击力。

3． Spring
它 是一个开源的项目，而且目前非常活跃；它基于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中要写很多代码、控制器过于灵活，缺少一个公用控制器

 

有关Hibernate优点和缺点的阐述

1.Hibernate优点：

（1）对象/关系数据库映射(Basic O/R Mapping)

它使用时只需要操纵对象，使开发更对象化，抛弃了数据库中心的思想，完全的面向对象思想。

（2）透明持久化(Persistent)

带有持久化状态的、具有业务功能的单线程对象，此对象生存期很短。这些对象可能是普通的JavaBeans/POJO，这个对象没有实现第三方框架 或者接口，唯一特殊的是他们正与（仅仅一个）Session相关联。一旦这个Session被关闭，这些对象就会脱离持久化状态，这样就可被应用程序的任 何层自由使用。（例如，用作跟表示层打交道的数据传输对象。）           

（3）事务Transaction (org.Hibernate.Transaction)

应用程序用来指定原子操作单元范围的对象，它是单线程的，生命周期很短。它通过抽象将应用从底层具体的JDBC、JTA以及CORBA事务隔离开。 某些情况下，一个Session之内可能包含多个Transaction对象。尽管是否使用该对象是可选的，但无论是使用底层的API还是使用 Transaction对象，事务边界的开启与关闭是必不可少的。

（4）它没有侵入性，即所谓的轻量级框架。

（5）移植性会很好。

（6）缓存机制。提供一级缓存和二级缓存。

（7）简洁的HQL编程。

2.Hibernate缺点：

（1）Hibernate在批量数据处理的时候是有弱势。

（2）针对某一对象(单个对象)简单的查/改/删/增，不是批量修改、删除，适合用Hibernate；而对于批量修改、删除，不适合用Hibernate，这也是OR框架的弱点;要使用数据库的特定优化机制的时候，不适合用Hibernate。

引用自：http://developer.51cto.com/art/200906/129451.htm

 

Hibernate 与 IBatis 的优缺点及可行性分析

    1.优点

    简单：

    易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。

    实用：

    提供了数据映射功能，提供了对底层数据访问的封装（例如ado.net），提供了dao框架，可以使我们更容易的开发和配置我们的dal层。

    灵活：

    通过sql基本上可以实现我们不使用数据访问框架可以实现的所有功能，或许更多。

    功能完整：

    提供了连接管理，缓存支持，线程支持，（分布式）事物管理，通过配置作关系对象映射等数据访问层需要解决的问题。提供了dao支持，并在dao框架中封装 了ado.net，Hibernate和datamapper.增强系统的可维护性：通过提供dal层，将业务逻辑和数据访问逻辑分离，使系统的设计更清 晰，更易维护，更易单元测试 。sql和代码的分离，提高了可维护性。

    2.缺点

    滞后性：

    还没有明确对。net2.0的支持。最新版本在2.0下编译可以，但有些单元测试 不能通过。

    不成熟，工程实践较少：ibatisnet在实际项目中的使用较少。 只是理论上可行。

    半orm，工具支持较少：需要我们自己写sql，并且。net下还未发现可以自动生成业务层类和配置文件的工具，这点和Hibernate不一 样，Hibernate会为我们的数据库直接产生sql，并有一些辅助工具。因此使用ibatis比Hibernate要多做一些工作。

    3.可行性

    没有最好的框架，只有最适合的框架。 存在的便是合理的，它存在就说明有它存在的道理。但它未必为我们存在。所以选择一个框架最主要的是看它对你有没有意义，意义有多大，是不是比其他框架带给 你的好处要多。没有绝对的优点也没有绝对的缺点，重要的是看在什么情况下讨论。

    上面说了部分的ibatis的优点和部分缺点。这些优点从理论上证明ibatis对任何数据持久层都合适，但未必是最好的选择。下面对上面的优缺点分别从两方面讨论。

    简单：

    我们都喜欢简单，简单意味着学习成本低，使用中出错的可能性低。同时，简单的东西一般来说功能不够强大。反过来，复杂的东西学习成本高，用起来不方便，并且团队没有很强的技术实力，一般不要使用。

    实用：

    解决了项目中需要解决的问题，这是任何实际工程中采用的框架和工具都应具有的性质，否则就不要拿到实际项目中来。

    灵活：

    灵活有两层意思，一种是简单易扩展，另一种是功能强大提供了很多选项。ibatis属于前者，Hibernate属于后者。两者各有优缺点。

    功能完整：

    ibatis的功能完整也是相对的，比我们自己开发的框架应该完整，但对比其他框架肯定也有一些解决不了的问题。

    增强系统的可维护性：利用ibatis可以做到sql和代码分离，可以设计出一个清晰的数据访问层（dal）。但项目架构是否科学合理，是否以维护，关键 不在ibatis，因 为它只是一个数据层框架。但是我们也不得不清楚，要想发挥ibatis的优势，我们需要做一些额外工作，比如最好设计dao接口，需要将业务层实体和对实 体的访问放在不同的工程中，同时需要维护xml配置文件。

    滞后性：

    ibatis组现在还没有提到要支持。net2.0，很多人在。net2.0下使用ibatis都出现了问题。所以如果要使用。net2.0开发，ibatis不是一个好选择，还需要等待。

    不成熟：

    开源的东西很难说成熟，但一般比我们自己写的框架要成熟。由于我们可以拿到他的源代码，所以关键在于我们能否驾驭它。

    半orm，工具支持少：

    这注定了ibatis不能从本质上提升开发效率，我们需要自己写sql，写实体类，写配置文件。但这也是它优越的地方，它没有为我们做的他多，所以我们就 有更多的施展空间。而且它非常适合那些并不能完全控制数据库的系统和需要利用数据库本身提供的高级特性的统计查询系统的开发。

    使用ibatis需要自己写sql，由于我们的sql不可能完全符合sql标准，比起Hibernate产生的sql来，可移植性差。不过由于我们更改 数据库的可能性较小，对我们来说sql符合标准以便可以在迁移到不同服务器 时代价最小并不是十分必要的。另一方面，Hibernate虽然可以屏蔽很多 数据库间的不同，但是却很难利用某些数据库的高级特性，比如oracle的分析统计函数。

    Hibernate不适合数据库模式不规范，约束不完整，需要大量复杂查询的系统，同时Hibernate的学习成本较高，完全掌握Hibernate也较困难，风险较大。

    自己写框架未必比ibatis的好，稳定，强大和可扩展。而且自己开发框架也需要较大的工作量。

    如果使用dotnet并且要选一个数据层框架，而系统中有相当一部分较复杂的sql，或数据库设计不合理，脏数据多，对性能和资源要求严格，ibatis 是一个比较不错的选择。他的那些缺点并不是致命的，而且也是有一些解决方案的。尤其是，当选用了ibatis的dataaccess作为dao框架时，我 们可以同时使用Hibernate，ado.net和datamapper（ibatisnet的核心组件），那样将会使风险降到最低，并且整个系统的 框架比较合理。

    另外，利用ibatis可以统一编码风格，节约开发成本，大家不会再把精力浪费到分页 连接池 主键生成等地方了，可以集中精力进行业务组件的编写。

    综上： 很多时候我们要在是自己开发框架和选用第三方框架和选用什么样的框架问题上进行综合考虑。考虑的标准当然是项目的当前情况和我们希望达到目的的一个平衡。

    ibatis只是封装了数据访问层，替我们做了部分的对象关系映射。但我们的代价是必须要写xml配置文件，相对于Hibernate我们还要写很多 sql.Hibernate通过工具直接从数据库模式生成实体类和基本的配置文件，而且大部分情况下不需要我们写sql，会较大的提升开发效率。但这些也 有很多的局限性，尤其是对环境的要求较高（数据库设计，对象设计，团队的协作等）。

    个人感觉ibatis对项目比较有意义的地方在于它小巧灵活，可扩展，封装了数据访问层（事务，缓存，异常，日志），并提供了dao框架支持。

    利用ibatis我们可以做到代码和sql的分离，只要sql能够解决的问题，ibatis就能帮我们较容易的解决，同时也使我们的项目对某一框架的依赖 性变小（因为ibatis是非侵入性的）。这将极大的降低项目风险，减少解决复杂问题的时间，使项目的维护变得简单。

    ibatis对于应用的修改，调试，扩充和维护将会变得容易自然。修改时，我们主要修改的是代表模型的实体对象，xml配置文件中的sql，和/或配置文 件的resultmap（很多时候是不需要的）。同时，sql和代码分离，我们不用在代码的stringbuffer的append方法之间寻找需要修改 的sql.配置文件中的sql便利了我们的调试和对sql的评审及以后的sql重用。

    利用一些框架在前期一般会拖慢开发效率。因为我们需要付出学习成本，很多时候，使用框架需要写很多配置文件，在使用不熟时开发速度较慢；同时利用框架往往 使系统代码量增大，比如model1和model2模型，开发效率应该还是model1快，四层的架构肯定比两层的代码量大。 但对于中后期开发和维护将会极大的提高效率。

    利用一些较完全的开发框架和代码生成工具，在前期会较大的提高开发效率，但在后期常常会拖慢进度，并有可能成为以后维护的梦魇。比如torque生成实体类和其对应的sql，虽大幅提高了效率，但修改负担较大。

    比较理想的开发方式是使用简单框架结合简单的代码生成工具。框架提供系统的基础服务，并规范开发。框架一方面提供了开发中某一方面的开发基础支持，比如数 据访问层，事务，日志，公用类，异常等。另一方面，也为开发定义了模式，定义了系统的基本轮廓。同时，通过简单的代码生成工具生成部分低级的代码。比如通 过工具从数据库模式生成实体类。这些类生成后我们可以自由修改。

    Hibernate是十分强大，比较完善的orm框架，不过这是它的优点也是它的缺点。 J2EE系统是否采用Hibernate3，是一个需要认真评估的问题。

    要想Hibernate工作的好，数据库的设计必须好。同时对于复杂的数据操作同时需要使用sql，Hibernate3对于直接使用sql的支持比Hibernate2要自然，这一点是可以接受的。

    Hibernate比较复杂，功能强大而灵活，要用好Hibernate确实不是很简单，当然spring框架提供了对Hibernate的封装，使Hibernate的使用变得简单了点。

    可以说ibatis在任何系统里都适用，但未必是最好选择。不过ibatis提供的思路是我们应该仔细考虑的。

    引用自：http://java.chinaitlab.com/Hibernate/787060.html