持久层请问JAVA三层架构，持久层，业务层，表现层，都该怎么理解？和MVC三层模型有什么区别

请问hibernate里面的持久层就是指 的类么，就是pojo？那不就是个实体类么？持久层是干什么的

持久层就是一些需要被持久化的类,就是这些类迟早是要望数据库里面保存的, SPRING的功能很强大,你没发现现在的框架虽然降低类耦合,但耦合还是很强,SPRING这个框架把类之间的耦合降到最低,几乎没有,不看配置文件你是不会知道哪个类和哪个类有关系的,有是用了依赖注入 而且SPRING还有面向方面编程的解决方案,也是为了程序分工更加明确 总之不建议新手看SPRING,

hibernate持久层设计有什么好处？

一、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之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。

持久层的交互 的理解

持久层，指的应该是数据持久化层吧。

它的交互分为两方面，向下，与数据库交互， 把数据存储到数据库中，或吧数据库中的数据提取出来。

向上，与业务逻辑层交互， 向业务路层提供业务数据，同时把业务逻辑处理后的数据保存。

什么是数据持久层

J2EE的三层结构是指表示层（Presentation），业务逻辑层（Business Logic）以及基础架构层（Infrastructure），这样的划分非常经典，但是在实际的项目开发法中，开发者通常对三层结构进行扩展来满足一些项目的具体要求，一个最常用的扩展就是将三层体系扩展为五层体系，即表示层(Presentation)、控制/中介层(Controller/Mediator)、领域层(Domain)、数据持久层(Data Persistence)和数据源层(Data Source)。

它其实是在三层架构中增加了两个中间层。

控制/中介层位于表示层和领域层之间，数据持久层位于领域层和基础架构层之间。

由于对象范例和关系范例这两大领域之间存在“阻抗不匹配”，所以把数据持久层单独作为J2EE体系的一个层提出来的原因就是能够在对象－关系数据库之间提供一个成功的企业级映射解决方案，尽最大可能弥补这两种范例之间的差异。

　　三种持久层主流解决方案 　　1、JDBC 　　许多开发者用JDBC进行数据库程序的开发。

此中方式很多情况下都使用DAO模式，采用SQL进行查询。

虽然用此方式可以使应用程序代码与具体的数据库厂商和数据库位置无关，不过JDBC是低级别的数据库访问方式，JDBC并不支持面向对象的数据库表示。

JDBC数据库表示完全围绕关系数据库模型。

在大型应用程序的DAO中书写这样的代码，维护量是非常大的。

　　2、EJB 　　在J2EE的规范中，为EJB定义了两种持久化的解决方案：一种是BMP，另一种是CMP。

其中CMP不需要将SQL语句加入到代码中。

目前，在采用J2EE的应用中，EJB CMP方式得到了广泛应用。

更加引人注意的是，随着EJB规范的发展，CMP也包含了一些高级关系的内容。

但是，CMP的使用比较复杂，对很多开发人员来说比较难以掌握。

而且，不是在所有的情况下都适合在系统中采用EJB，而且想要非常清楚的了解EJB规范也是非常费时的。

在用EJB编码前，先要让专家理解API，然后需要了解每一个容器部署时所要关注的技术。

此外，许多情况下商用容器的性能和支持也不是很好。

　　3、JDO 　　JDO是一个存储java对象的规范，JDO规范1.0的提出可以使你将精力集中在设计Java对象模型，然后在企业应用软件架构的不同层面中存储传统的Java对象（Plain Old Java Objects，简称POJOs），采用JDOQL语言进行SQL操作。

一些公司（包括sun）企图根据JDO规范进行设计并实现JDO产品，然而他们都不能很好的进行实现，并且性能优化上比较差。

请问JAVA三层架构，持久层，业务层，表现层，都该怎么理解？和MVC三层模型有什么区别

持久层用来固化数据，如常说的DAO层，操作数据库将数据入库 业务层用来实现整体的业务逻辑 如 前台获得了数据，逻辑层去解析这些数据，效验这些数据等操作 表现层很好解释 你现在看到的网页 一些界面 都属于表现层的东西可以用一些Html，jsp，Swing来实现 至于mvc么对应的是 model（模型） view（视图） Controller（控制） 在javaweb中就很好理解了再XX系统中，前台页面属于view 贯穿前台后台持久层的一套模型就是model（EJB，Spring来实现） 而连接前台后台进行逻辑操作的就是Controller（Struts来实现）