简略解析J2EE数据持久层设计
日期：2014-05-19 浏览次数：20624 次
简单解析J2EE数据持久层设计
*
简单解析J2EE数据持久层设计
* http://developer.51cto.com 2009-09-23 17:11 佚名 javaresearch 我要评论(0)
数据持久层的设计目标是为整个项目提供一个高层、统一、安全和并发的数据持久机制。数据持久层，是基于J2EE体系结构，并采用了Hibernate作为持久映射框架。
Hibernate有很多值得学习的地方，这里我们主要介绍在Hibernate中J2EE数据持久层设计。
数据持久层的设计目标是为整个项目提供一个高层、统一、安全和并发的数据持久机制。
完成对各种数据进行持久化的编程工作，并为系统业务逻辑层提供服务。数据持久层提供了数据访问方法，能够使其它程序员避免手工编写程序访问数据持久层(Persistene layer)，使其专注于业务逻辑的开发，并且能够在不同项目中重用映射框架，大大简化了数据增、删、改、查等功能的开发过程，同时又不丧失多层结构的天然优势，继承延续J2EE特有的可伸缩性和可扩展性。
1 数据持久层及ORM映射框架
笔者从事的项目中的数据持久层，是基于J2EE体系结构，并采用了Hibernate作为持久映射框架。
Hibernate是一种新的ORM映射工具，是JDBC的轻量级的对象封装。Hibernate可以用在JDBC可以使用的任何场合，例如 Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。Hibernate不仅提供了从Java类到数据表之间的映射，也提供了数据查询和恢复机制。相对于使用JDBC和SQL来手工操作数据库，使用Hibernate，可以大大减少操作数据库的工作量。
Hibernate是一个和JDBC密切关联的、独立的对象持久层框架，可以搭配各种App Server、Web Server、EJB Container共同使用，Hibernate的兼容性仅同JDBC驱动、底层数据库产品间有一定的关系，但是和使用它的Java程序、App Server没有任何关系，也不存在兼容性问题。而且事实表明Hibernate可以和多种Web服务器或者应用服务器良好集成，如今已经支持几乎所有的流行的数据库服务器（达16种）。
在较为常用的数据持久层方案中，Hibernate无疑是最优秀的，下面是对各种持久方案的比较。
¨ 流行的数据持久层架构：
Business Layer <-> Session Bean <-> Entity Bean <-> DB
¨ 为了解决性能障碍的替代架构：
Business Layer <-> DAO <-> JDBC <-> DB
¨ 使用Hibernate来提高上面架构的开发效率的架构：
Business Layer <-> DAO <-> Hibernate <-> DB
我们就上面3个架构来作如下分析。
(1)内存消耗：采用JDBC的架构无疑是最省内存的，Hibernate的架构次之，EB的架构最差。
(2)运行效率：如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通 JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。 EB的架构效率会差的很远。
(3)开发效率：在有Eclipse、JBuilder等开发工具的支持下，对于简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。
2 数据持久层设计
复杂性是应用开发过程中最令人头疼的一个问题。每当在一个应用中增加一个功能时，它的复杂性通常呈几何级的增长。这种复杂性往往导致程序的开发无法再继续下去。这也是现在为什么许多应用只有Beta版本而没有正式版的原因。
专家将应用开发过程产生的复杂性分为两类，即非本质的（accidental）和本质的（essential）。本质的复杂性是对于解决目标问题所必然产生的复杂性，非本质的复杂性是由于选择了不适当的开发工具和设计工具而产生的复杂性。对于一个功能确定的程序来讲，本质的复杂性是确定的，而非本质的复杂性则是没有限制的。因此，一个应用的开发要想较顺利地取得成功，就需要尽可能地减少非本质的复杂性。
设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式，也会使新系统开发者更加容易理解其设计思路。
衡量一个系统优秀与否的关键因素，除了能够满足用户需求外还有如下方面：首先是灵活性。灵活性意指这种结构或模式不依赖于任何实际应用，应该与操作系统、应用程序无关。提供独立的结构，可以提供最大的重用。其次是可扩展性。随着业务的扩展，新的业务不断增加，业务逻辑自然增加，系统必然会进行修改或添加相应功能模块。再次是可配置性。最后是安全性。
数据持久层的设计采纳了多种设计模式，最大限度的降低了系统内部各模块、子系统间的耦合性，使得系统相对易于扩展，并且能够在进行改变时，保证持久层的业务逻辑层相对稳定，基本不需要因持久层的调整改变而进行逻辑层的变动。
笔者在项目中采用了如下设计模式。
1) 整体架构——MVC模式（模型-视图-控制器）
模型（Model）：模型包含完成任务所需要的所有的行为和数据。在数据持久层中，模型即为值对象以及数据访问对象。
视图（View）：数据持久层中，视图就是持久层同其它层进行数据交换的值对象（Transfer Object）和视图助手对象。
¨ 控制器（Controller）：持久层所需的控制相对简单，因此集成到了控制代理中。
持久层整体采用MVC模式，使得整个数据持久层的实现部分与项目的业务逻辑部分隔离开来，能够实现对接口作大的修改而不需要对相应的模型进行修改。
*
简单解析J2EE数据持久层设计
* http://developer.51cto.com 2009-09-23 17:11 佚名 javaresearch 我要评论(0)
数据持久层的设计目标是为整个项目提供一个高层、统一、安全和并发的数据持久机制。数据持久层，是基于J2EE体系结构，并采用了Hibernate作为持久映射框架。
Hibernate有很多值得学习的地方，这里我们主要介绍在Hibernate中J2EE数据持久层设计。
数据持久层的设计目标是为整个项目提供一个高层、统一、安全和并发的数据持久机制。
完成对各种数据进行持久化的编程工作，并为系统业务逻辑层提供服务。数据持久层提供了数据访问方法，能够使其它程序员避免手工编写程序访问数据持久层(Persistene layer)，使其专注于业务逻辑的开发，并且能够在不同项目中重用映射框架，大大简化了数据增、删、改、查等功能的开发过程，同时又不丧失多层结构的天然优势，继承延续J2EE特有的可伸缩性和可扩展性。
1 数据持久层及ORM映射框架
笔者从事的项目中的数据持久层，是基于J2EE体系结构，并采用了Hibernate作为持久映射框架。
Hibernate是一种新的ORM映射工具，是JDBC的轻量级的对象封装。Hibernate可以用在JDBC可以使用的任何场合，例如 Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。Hibernate不仅提供了从Java类到数据表之间的映射，也提供了数据查询和恢复机制。相对于使用JDBC和SQL来手工操作数据库，使用Hibernate，可以大大减少操作数据库的工作量。
Hibernate是一个和JDBC密切关联的、独立的对象持久层框架，可以搭配各种App Server、Web Server、EJB Container共同使用，Hibernate的兼容性仅同JDBC驱动、底层数据库产品间有一定的关系，但是和使用它的Java程序、App Server没有任何关系，也不存在兼容性问题。而且事实表明Hibernate可以和多种Web服务器或者应用服务器良好集成，如今已经支持几乎所有的流行的数据库服务器（达16种）。
在较为常用的数据持久层方案中，Hibernate无疑是最优秀的，下面是对各种持久方案的比较。
¨ 流行的数据持久层架构：
Business Layer <-> Session Bean <-> Entity Bean <-> DB
¨ 为了解决性能障碍的替代架构：
Business Layer <-> DAO <-> JDBC <-> DB
¨ 使用Hibernate来提高上面架构的开发效率的架构：
Business Layer <-> DAO <-> Hibernate <-> DB
我们就上面3个架构来作如下分析。
(1)内存消耗：采用JDBC的架构无疑是最省内存的，Hibernate的架构次之，EB的架构最差。
(2)运行效率：如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通 JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。 EB的架构效率会差的很远。
(3)开发效率：在有Eclipse、JBuilder等开发工具的支持下，对于简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。
2 数据持久层设计
复杂性是应用开发过程中最令人头疼的一个问题。每当在一个应用中增加一个功能时，它的复杂性通常呈几何级的增长。这种复杂性往往导致程序的开发无法再继续下去。这也是现在为什么许多应用只有Beta版本而没有正式版的原因。
专家将应用开发过程产生的复杂性分为两类，即非本质的（accidental）和本质的（essential）。本质的复杂性是对于解决目标问题所必然产生的复杂性，非本质的复杂性是由于选择了不适当的开发工具和设计工具而产生的复杂性。对于一个功能确定的程序来讲，本质的复杂性是确定的，而非本质的复杂性则是没有限制的。因此，一个应用的开发要想较顺利地取得成功，就需要尽可能地减少非本质的复杂性。
设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式，也会使新系统开发者更加容易理解其设计思路。
衡量一个系统优秀与否的关键因素，除了能够满足用户需求外还有如下方面：首先是灵活性。灵活性意指这种结构或模式不依赖于任何实际应用，应该与操作系统、应用程序无关。提供独立的结构，可以提供最大的重用。其次是可扩展性。随着业务的扩展，新的业务不断增加，业务逻辑自然增加，系统必然会进行修改或添加相应功能模块。再次是可配置性。最后是安全性。
数据持久层的设计采纳了多种设计模式，最大限度的降低了系统内部各模块、子系统间的耦合性，使得系统相对易于扩展，并且能够在进行改变时，保证持久层的业务逻辑层相对稳定，基本不需要因持久层的调整改变而进行逻辑层的变动。
笔者在项目中采用了如下设计模式。
1) 整体架构——MVC模式（模型-视图-控制器）
模型（Model）：模型包含完成任务所需要的所有的行为和数据。在数据持久层中，模型即为值对象以及数据访问对象。
视图（View）：数据持久层中，视图就是持久层同其它层进行数据交换的值对象（Transfer Object）和视图助手对象。
¨ 控制器（Controller）：持久层所需的控制相对简单，因此集成到了控制代理中。
持久层整体采用MVC模式，使得整个数据持久层的实现部分与项目的业务逻辑部分隔离开来，能够实现对接口作大的修改而不需要对相应的模型进行修改。
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
