Hibernaet的作用.doc

第一：数据库连接不需要我们自己来管理，如打开和关闭（优点吧）第二：Hibernate对原来的SQL语句进行了封装，以前写很多SQL语句，现在你在保存的时候直接可以用 SAVE（对象）来实现了。（节省代码吧）第三：原来是对表操作，现在是对对象操作，想法上是不是更好呢？都是对象。Hibernate优点(1) 对象/关系数据库映射(ORM)它使用时只需要操纵对象，使开发更对象化，抛弃了数据库中心的思想，完全的面向对象思想(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框架的弱点；要使用数据库的特定优化机制的时候，不适合用Hibernate1.strutsstruts框架具有组件的模块化，灵活性和重用性的优点，同时简化了基于MVC的web应用程序的开发。优点：Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。除此之外，Struts的优点主要集中体现在两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。另外，struts是业界 标准 （很多成功案例），学习资源丰富，HTML标签非常优秀缺点：Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。Struts将MVC的Controller一分为三，在获得结构更加清晰的同时，也增加了系统的复杂度。ActionForms使用不便、无法进行单元测试（StrutsTestCase只能用于集成）2HibernateHibernate是一个开放源代码的对象关系映射框架，它对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中要写很多代码、控制器过于灵活，缺少一个公用控制器=java的spring框架有什么好处阿?说白了，原来 关系都是在类里完成的 比如说 User( 接口) user = new User();用了spring 以后 在配置文件里 就可以指定 这个user(接口) 到底用那个实现类去实现，便于后期对项目维护，如果以后老板要换一个逻辑 就可以直接换一个实现类，在配置文件里一改 目的就达到了，不必要打开JAVA文件重新写=在SSH框假中spring充当了管理容器的角色。我们都知道Hibernate用来做持久层，因为它将JDBC做了一个良好的封装，程序员在与数据库进行交互时可以不用书写大量的SQL语句。Struts是用来做应用层的，他它负责调用业务逻辑serivce层。所以SSH框架的流程大致是：Jsp页面-Struts-Service（业务逻辑处理类）-Hibernate（左到右）struts负责控制Service（业务逻辑处理类），从而控制了Service的生命周期，这样层与层之间的依赖和强，属于耦合。这时，使用spring框架就起到了控制Action对象（Strus中的）和Service类的作用，两者之间的关系就松散了，Spring的Ioc机制（控制反转和依赖注入）正是用在此处。Spring的Ioc（控制反转和依赖注入）控制反转：就是由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直接操控。依赖注入：组件之间的依赖关系由容器在运行期决定 ，由容器动态的将某种依赖关系注入到组件之中。从上面我们不难看出：从头到尾Action仅仅是充当了Service的控制工具，这些具体的业务方法是怎样实现的，他根本就不会管，也不会问，他只要知道这些业务实现类所提供的方法接口就可以了。而在以往单独使用Struts框架的时候，所有的业务方法类的生命周期，甚至是一些业务流程都是由Action来控制的。层与层之间耦合性太紧密了，既降低了数据访问的效率又使业务逻辑看起来很复杂，代码量也很多。，Spring容器控制所有Action对象和业务逻辑类的生命周期，由与上层不再控制下层的生命周期，层与层之间实现了完全脱耦，使程序运行起来效率更高，维护起来也方便。使用Spring的第二个好处（AOP应用）：事务的处理：在以往的JDBCTemplate中事务提交成功，异常处理都是通过Try/Catch 来完成，而在Spring中。Spring容器集成了TransactionTemplate，她封装了所有对事务处理的功能，包括异常时事务回滚，操作成功时数据提交等复杂业务功能。这都是由Spring容器来管理，大大减少了程序员的代码量，也对事务有了很好的管理控制。Hibernate中也有对事务的管理，hibernate中事务管理是通过SessionFactory创建和维护Session来完成。而Spring对SessionFactory配置也进行了整合，不需要在通过hibernate.cfg.xml来对SessionaFactory进行设定。这样的话就可以很好的利用Sping对事务管理强大功能。避免了每次对数据操作都要现获得Session实例来启动事务/提交/回滚事务还有繁琐的Try/Catch操作。这些也就是Spring中的AOP（面向切面编程）机制很好的应用。一方面使开发业务逻辑更清晰、专业分工更加容易进行。另一方面就是应用Spirng AOP隔离降低了程序的耦合性使我们可以在不同的应用中将各个切面结合起来使用大大提高了代码重用度。=一、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之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。在SSH框假中spring充当了管理容器的角色。我们都知道Hibernate用来做持久层，因为它将JDBC做了一个良好的封装，程序员在与数据库进行交互时可以不用书写大量的SQL语句。Struts是用来做应用层的，他它负责调用业务逻辑serivce层。所以SSH框架的流程大致是：Jsp页面-Struts-Service（业务逻辑处理类）-Hibernate（左到右）struts负责控制Service（业务逻辑处理类），从而控制了Service的生命周期，这样层与层之间的依赖和强，属于耦合。这时，使用spring框架就起到了控制Action对象（Strus中的）和Service类的作用，两者之间的关系就松散了，Spring的Ioc机制（控制反转和依赖注入）正是用在此处。 Spring的Ioc（控制反转和依赖注入） 控制反转：就是由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直接操控。 依赖注入：组件之间的依赖关系由容器在运行期决定 ，由容器动态的将某种依赖关系注入到组件之中。 从上面我们不难看出：从头到尾Action仅仅是充当了Service的控制工具，这些具体的业务方法是