java名词解释汇总.docx

java名词解释汇总.docx

《java名词解释汇总.docx》由会员分享，可在线阅读，更多相关《java名词解释汇总.docx（12页珍藏版）》请在冰豆网上搜索。

java名词解释汇总

以前搜集的java名词解释汇总

什么是DTO?

DTO就是DataTransferObject,数据传输对象。

DTO主要负责client（WEB层）和业务层的数据传递。

DTO简单的就是一些Java类型，比如:

String,Integer,甚至List,Map等，更多就是POJO了，用属性承载数据。

虽然只有属性的DTO被一些大师如MartinFowler认为是“贫血的”，但我认为DTO很好的履行了它的职责：

描述业务接口，传输业务数据。

什么是POJO?

POJO是PlainOldJavaObject，它的产生源于BussinessOjbect的实现，相对应的技术有EntityBean。

可以作为一种轻量级的业务对象模型。

这个在Hibernate当中得到应用，并且EJB3.0的规范里也增加POJO作为相应的部分。

简单的说就是只有getter,setter以及简单的参数处理,没有具体业务逻辑的java类.

什么是ORM?

  O/RMapping--ObjectRelationalMapping（对象关系映射）的缩写.对象角色建模（ORM）提供了概念性的、易于理解的模型化数据的方法。

ORM方法论基于三个核心原则：

　　·简单。

以最基本的形式建模数据。

　　·传达性。

数据库结构被任何人都能理解的语言文档化。

　　·精确性。

基于数据模型创建正确标准化了的结构。

　　典型地，建模者通过收集来自那些熟悉应用程序但不熟练的数据建模者的人的信息开发信息模型。

建模者必须能够用非技术企业专家可以理解的术语在概念层次上与数据结构进行通讯。

建模者也必须能以简单的单元分析信息，对样本数据进行处理。

ORM专门被设计为改进这种联系。

　　规则表达式 

　　ORM把应用程序世界表示为具有角色（关系中的部分）的一组对象（实体或值）。

ORM有时也称为基于事实的建模，因为它把相关数据描述为基本事实。

这些事实如果分割为再小的事实就会丢失信息。

简单事实的一些例子包括：

　　·人有电话

　　·人住在某个地方 

　　·人生于某个日期

　　·人在某个日期被雇佣

　　这些事实相应的ORM模型如下：

图1.对象角色模型

　　图中的圆代表对象；矩形代表论断。

在ORM中，象在逻辑中一样，一个论断只是带有对象洞的语句。

箭头和点代表系统中的约束。

　　例如，在"人有电话"这个事实的诊断上的箭头可以翻译为：

　　有可能某个人有多于一个电话，并且至少有一个人有电话。

　　在"人生于某个日期"这个事实中，在论断上的箭头与连接对象与论断的点的结合表明：

　　每个人确切地出生于一个日期。

　　与ER的比较 

　　实体关系（ER）是另一种类型的数据库建模。

ORM模型的简单性与ER相应部分的比较：

图2.实体关系

　　ORM以简单对象和论断的形式描述企业事实，而实体关系方法论以术语实体（拥有属性并参与关系）描述世界。

在图1的ORM例子中，人，电话，地址和日期都表示为扮演有相互联系的角色的对象。

在ER例子中，人是一个实体，它由属性：

地址和电话进行描述。

　　例如，如果要把地址分解为街道，城市，州，ZIP码，那么必须把地址改变为具有相应属性的实体类型，结果会改变人与地址间的关系。

尽管在上面的ORM模型中表示的约束也可以在ER中表示，但只要向模型中增加节点，或编写应用程序代码对模型进行补充，就可以表示其它约束。

　　ORM的优点

　　ORM提供的不只是描述不同对象间关系的一个简单而直接的方式。

从示例中，可以看出ORM还提供了灵活性。

使用ORM创建的模型比使用其它方法创建的模型更有能力适应系统的变化。

另外，ORM允许非技术企业专家按样本数据谈论模型，因此他们可以使用真实世界的数据验证模型。

因为ORM允许重用对象，数据模型能自动映射到正确标准化的数据库结构。

　　ORM模型的简单性简化了数据库查询过程。

使用ORM查询工具，用户可以访问期望数据，而不必理解数据库的底层结构。

　　数据库生成和遍历引挚

　　象所有优秀的模型方法一样，ORM也不只是一个概念。

它包含了不同的设计过程以帮助建模者映射概念的和逻辑的模型，或使用转换引挚在这些模型间转换。

　　ORM模型也能够自动地映射到大多数流行的关系型数据库所实现的数据库结构。

检查前面的例子，ORM模型能自动生成ER图表或逻辑模型（可以翻译为SQL代码，并适用于所选择的数据库）。

　　总结

　　利用非技术企业专家的知识对于确保应用程序满足企业需求是重要的。

ORM，VisualStudio.NET的一个特性，是一个最初的、易于使用的概念性数据模型方法。

通过使用不只是只有数据库专家才能理解的语言，ORM使那些充分理解了企业对应用程序需求的人能直接参与设计。

　　ORM还支持完全的遍历引挚，因此一旦定义了企业需求，它们就能迅速的转化为逻辑和物理数据库图表。

使用ORM，组织可以提高应用程序开发的效率，确保企业需求能被正确交付。

论坛竟然不支持图片 

0&&image.height>0）{if（image.width>=510）{this.width=510;this.height=image.height*510/image.width;}}"align=absMiddleborder=0>

VO与PO的概念

O/RMapping--ObjectRelationalMapping（对象关系映射）的缩写。

通俗点讲，就是将对象与关系数据绑定，用对象来表示关系数据。

如图：

VO--ValueObject值对象。

PO--PersistentObject持久对象。

它们的基本形式和写法如下：

publicclassUser{

  privateStringid;

  privateStringname;

  publicvoidsetId（StringargId）{

      this.id=argId;

  }

  publicStringgetId（）{

      returnthis.id;

  }

  publicvoidsetName（StringargName）{

      this.name=argName;

  }

  publicStringgetName（）{

      returnthis.Name;

  }

}

虽然它们的形式与写法基本相同，但意义却大不相同。

1.VO是用new关键字创建，由GC回收的。

  PO是向数据库中添加新数据时创建，删除数据库中数据时删除的。

并且它只能存活在一个数据库连接中，当连接断开时，将被销毁。

2.VO是值对象，精确点讲它是业务对象，是存活在业务层的，是业务逻辑使用的，它存活的目的就是为数据提供一个生存的地方。

  PO是有状态的，每个属性代表其当前的状态。

它是物理数据的对象表示。

使用它，可以使我们的程序与物理数据解耦，并且可以简化对象数据与物理数据之间的转换。

3.VO的属性是根据当前业务的不同而不同的，也就是说，它的每一个属性都一一对应当前业务逻辑所需要的数据的名称。

  PO的属性是跟数据库表的字段一一对应的。

OSIV：

OpenSessionInView，在B/S系统中通常采用这种方式来更好的去支持Lazy

load，意思就是在View加载前打开Session，在View加载完毕后关闭Session的方

式，在Spring中有OpenSessionInViewFilter，可参考或直接使用。

转自javaeye

pojo与po的概念

POJO=pureoldjavaobjectorplainordinaryjavaobjectorwhatever. 

PO=persisentobject持久对象 

就是说在一些Object/RelationMapping工具中，能够做到维护数据库表记录的persisentobject完全是一个符合JavaBean规范的纯Java对象，没有增加别的属性和方法。

全都是这样子的：

java代码:

publicclassUser{ 

  privatelongid; 

  privateStringname; 

  publicvoidsetId（longid）{ 

this.id=id; 

}  

publicvoidsetName（Stringname）{ 

this.name=name; 

} 

publiclonggetId（）{ 

returnid; 

}  

publicStringgetName（）{ 

returnname; 

} 

} 

--------------------------------------------------------------------------- 

首先要区别持久对象和POJO。

持久对象实际上必须对应数据库中的entity，所以和POJO有所区别。

比如说POJO是由new创建，由GC回收。

但是持久对象是insert数据库创建，由数据库delete删除的。

基本上持久对象生命周期和数据库密切相关。

另外持久对象往往只能存在一个数据库Connection之中，Connnection关闭以后，持久对象就不存在了，而POJO只要不被GC回收，总是存在的。

由于存在诸多差别，因此持久对象PO（PersistentObject）在代码上肯定和POJO不同，起码PO相对于POJO会增加一些用来管理数据库entity状态的属性和方法。

而ORM追求的目标就是要PO在使用上尽量和POJO一致，对于程序员来说，他们可以把PO当做POJO来用，而感觉不到PO的存在。

JDO的实现方法是这样的：

1、编写POJO 

2、编译POJO 

3、使用JDO的一个专门工具，叫做Enhancer，一般是一个命令行程序，手工运行，或者在ant脚本里面运行，对POJO的class文件处理一下，把POJO替换成同名的PO。

4、在运行期运行的实际上是PO，而不是POJO。

该方法有点类似于JSP，JSP也是在编译期被转换成Servlet来运行的，在运行期实际上运行的是Servlet，而不是JSP。

Hibernate的实现方法比较先进：

1、编写POJO 

2、编译POJO 

3、直接运行，在运行期，由Hibernate的CGLIB动态把POJO转换为PO。

由此可以看出Hibernate是在运行期把POJO的字节码转换为PO的，而JDO是在编译期转换的。

一般认为JDO的方式效率会稍高，毕竟是编译期转换嘛。

但是Hibernate的作者GavinKing说CGLIB的效率非常之高，运行期的PO的字节码生成速度非常之快，效率损失几乎可以忽略不计。

实际上运行期生成PO的好处非常大，这样对于程序员来说，是无法接触到PO的，PO对他们来说完全透明。

可以更加自由的以POJO的概念操纵PO。

另外由于是运行期生成PO，所以可以支持增量编译，增量调试。

而JDO则无法做到这一点。

实际上已经有很多人在抱怨JDO的编译期Enhancer问题了，而据说JBossDO将采用运行期生成PO字节码，而不采用编译期生成PO字节码。

另外一个相关的问题是，不同的JDO产品的Enhancer生成的PO字节码可能会有所不同，可能会影响在JDO产品之间的可移植性，这一点有点类似EJB的可移植性难题。

----------------------------------------------------------------------------------- 

由这个问题另外引出一个JDO的缺陷。

由于JDO的PO状态管理方式，所以当你在程序里面get/set的时候，实际上不是从PO的实例中取values，而是从JDOStateManager中取出来，所以一旦PM关闭，PO就不能进行存取了。

在JDO中，也可以通过一些办法使得PO可以在PM外面使用，比如说定义PO是transient的，但是该PO在PM关闭后就没有POidentity了。

无法进行跨PM的状态管理。

而Hibernate是从PO实例中取values的，所以即使Session关闭，也一样可以get/set，可以进行跨Session的状态管理。

在分多层的应用中，由于持久层和业务层和web层都是分开的，此时Hibernate的PO完全可以当做一个POJO来用，也就是当做一个VO，在各层间自由传递，而不用去管Session是开还是关。

如果你把这个POJO序列化的话，甚至可以用在分布式环境中。

（不适合lazyloading的情况） 

但是JDO的PO在PM关闭后就不能再用了，所以必须在PM关闭前把PO拷贝一份VO，把VO传递给业务层和web层使用。

在非分布式环境中，也可以使用ThreadLocal模式确保PM始终是打开状态，来避免每次必须进行PO到VO的拷贝操作。

但是不管怎么说，这总是权宜之计，不如Hibernate的功能强。

什么是持久化和对象关系映射ORM技术?

何谓“持久化”

持久（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。

持久化的主要应用是将内存中的数据存储在关系型的数据库中，当然也可以存储在磁盘文件中、XML数据文件中等等。

何谓“持久层”

持久层（PersistenceLayer），即专注于实现数据持久化应用领域的某个特定系统的一个逻辑层面，将数据使用者和数据实体相关联。

何谓“对象数据映射（ORM）”

ORM-Object/RelationalMapper，即“对象-关系型数据映射组件”。

对于O/R，即Object（对象）和Relational（关系型数据），表示必须同时使用面向对象和关系型数据进行开发。

备注：

建模领域中的ORM为Object/RoleModeling（对象角色建模）。

另外这里是“O/RMapper”而非“O/RMapping”。

相对来讲，O/RMapping描述的是一种设计思想或者实现机制，而O/RMapper指以O/R原理设计的持久化框架（Framework），包括O/R机制还有SQL自生成，事务处理，Cache管理等。

除了ORM技术，还有以下几种持久化技术

主动域对象模式

它是在实现中封装了关系数据模型和数据访问细节的一种形式。

在J2EE架构中，EJB组件分为会话EJB和实体EJB。

会话EJB通常实现业务逻辑，而实体EJB表示业务实体。

实体EJB又分为两种：

由EJB本身管理持久化，即BMP（Bean-ManagedPersistence）；有EJB容器管理持久化，即CMP（Container-ManagedPersistence）。

BMP就是主动域对象模式的一个例子，BMP表示由实体EJB自身管理数据访问细节。

主动域对象本身位于业务逻辑层，因此采用主动域对象模式时，整个应用仍然是三层应用结构，并没有从业务逻辑层分离出独立的持久化层。

JDO模式

JavaDataObjects（JDO）是SUN公司制定的描述对象持久化语义的标准API。

严格的说，JDO并不是对象-关系映射接口，因为它支持把对象持久化到任意一种存储系统中，包括关系数据库、面向对象的数据库、基于XML的数据库，以及其他专有存储系统。

由于关系数据库是目前最流行的存储系统，许多JDO的实现都包含了对象-关系映射服务。

CMP模式

在J2EE架构中，CMP（Container-ManagedPersistence）表示由EJB容器来管理实体EJB的持久化，EJB容器封装了对象-关系的映射及数据访问细节。

CMP和ORM的相似之处在于，两者都提供对象-关系映射服务，都把对象持久化的任务从业务逻辑中分离出来。

区别在于CMP负责持久化实体EJB组件，而ORM负责持久化POJO，它是普通的基于JavaBean形式的实体域对象。

一般把基于JavaBean形式的实体域对象称为POJO（PlainOldJavaObject），意为又普通又古老的Java对象的意思。

随着各种ORM映射工具的日趋成熟和流行，POJO有重现光彩，它和基于CMP的实体EJB相比，即简单又具有很高的可移植性，因此联合使用ORM映射工具和POJO，已经成为一种越来越受欢迎的且用来取代CMP的持久化方案。

POJO的缺点就是无法做远程调用，不支持分布式计算。

为什么要做持久化和ORM设计

在目前的企业应用系统设计中，MVC，即Model（模型）-View（视图）-Control（控制）为主要的系统架构模式。

MVC中的Model包含了复杂的业务逻辑和数据逻辑，以及数据存取机制（如JDBC的连接、SQL生成和Statement创建、还有ResultSet结果集的读取等）等。

将这些复杂的业务逻辑和数据逻辑分离，以将系统的紧耦合关系转化为松耦合关系（即解耦合），是降低系统耦合度迫切要做的，也是持久化要做的工作。

MVC模式实现了架构上将表现层（即View）和数据处理层（即Model）分离的解耦合，而持久化的设计则实现了数据处理层内部的业务逻辑和数据逻辑分离的解耦合。

而ORM作为持久化设计中的最重要也最复杂的技术，也是目前业界热点技术。

简单来说，按通常的系统设计，使用JDBC操作数据库，业务处理逻辑和数据存取逻辑是混杂在一起的。

一般基本都是如下几个步骤：

1、建立数据库连接，获得Connection对象。

2、根据用户的输入组装查询SQL语句。

3、根据SQL语句建立Statement对象或者PreparedStatement对象。

4、用Connection对象执行SQL语句，获得结果集ResultSet对象。

5、然后一条一条读取结果集ResultSet对象中的数据。

6、根据读取到的数据，按特定的业务逻辑进行计算。

7、根据计算得到的结果再组装更新SQL语句。

8、再使用Connection对象执行更新SQL语句，以更新数据库中的数据。

7、最后依次关闭各个Statement对象和Connection对象。

由上可看出代码逻辑非常复杂，这还不包括某条语句执行失败的处理逻辑。

其中的业务处理逻辑和数据存取逻辑完全混杂在一块。

而一个完整的系统要包含成千上万个这样重复的而又混杂的处理过程，假如要对其中某些业务逻辑或者一些相关联的业务流程做修改，要改动的代码量将不可想象。

另一方面，假如要换数据库产品或者运行环境也可能是个不可能完成的任务。

而用户的运行环境和要求却千差万别，我们不可能为每一个用户每一种运行环境设计一套一样的系统。

所以就要将一样的处理代码即业务逻辑和可能不一样的处理即数据存取逻辑分离开来，另一方面，关系型数据库中的数据基本都是以一行行的数据进行存取的，而程序运行却是一个个对象进行处理，而目前大部分数据库驱动技术（如ADO.NET、JDBC、ODBC等等）均是以行集的结果集一条条进行处理的。

所以为解决这一困难，就出现ORM这一个对象和数据之间映射技术。

举例来说，比如要完成一个购物打折促销的程序，用ORM思想将如下实现（引自《深入浅出Hibernate》）：

业务逻辑如下：

publicDoublecalcAmount（Stringcustomerid,doubleamount） 

{

  //根据客户ID获得客户记录

  Customercustomer=CustomerManager.getCustomer（custmerid）; 

  //根据客户等级获得打折规则

  Promotionpromotion=PromotionManager.getPromotion（customer.getLevel（））; 

  //累积客户总消费额，并保存累计结果

  customer.setSumAmount（customer.getSumAmount（）.add（amount）; 

  CustomerManager.save（customer）; 

  //返回打折后的金额

  returnamount.multiply（protomtion.getRatio（））; 

}

这样代码就非常清晰了，而且与数据存取逻辑完全分离。

设计业务逻辑代码的时候完全不需要考虑数据库JDBC的那些千篇一律的操作，而将它交给CustomerManager和PromotionManager两个类去完成。

这就是一个简单的ORM设计，实际的ORM实现框架比这个要复杂的多。

目前有哪些流行的ORM产品

目前众多厂商和开源社区都提供了持久层框架的实现，常见的有

ApacheOJB（http:

//db.apache.org/ojb/）

Cayenne（http:

//objectstyle.org/cayenne/）

Jaxor（）

Hibernate（http:

//www.hibernate.org）

iBatis（）

jRelationalFramework（）

mirage（http:

//itor.cq2.org/en/oss/mirage/toon）

SMYLE（http:

//www.drjava.de/smyle）

TopLink（

其中TopLink是Oracle的商业产品，其他均为开源项目。

其中Hibernate的轻量级ORM模型逐步确立了在JavaORM架构中领导地位，甚至取代复杂而又繁琐的EJB模型而成为事实上的JavaORM工业标准。

而且其中的许多设计均被J2EE标准组织吸纳而成为最新EJB3.0规范的标准，这也是开源项目影响工业领域标准的有力见证。