作为一个大四即将毕业的毕业生,技术会的多并不重要,我觉得重要的是基础,这样才能才职场中如鱼得水般地学习。废话不多说,下面开始讲解这些概念。
POJO
全称:Plain Ordinary Java Object,简单普通java对象,一般使用在数据库表映射,即一个字段对应一个属性。
PO
全称:Persistant Object,持久化对象,一般存储数据库中映射之后的数据,一条记录对应一个PO。相当于将POJO持久化成PO。
DTO
全称:Data Transfer Object,数据传输对象,一般用于数据层向外层发送需要的数据格式(部分字段),这样可以加快发送效率。
DAO
全称:Data Access Object,数据访问对象,就是学习SSM时候的DAO层。用于数据库和外层作为持久化数据的传输。
BO
全称:Business Object,业务对象,一般使用于业务逻辑层。用于存储复杂的数据结构,比如将会数据库数据进行计算,保存不同结果,也是一种BO对象。
VO
全称:View Object,表现对象,一般使用前端页面数据显示。
前言:
在Java开发中经常遇到这些概念问题,有的可能理解混淆,有的可能理解不到位,特此花了很多时间理顺了这些概念。不过有些概念实际开发中并没有使用到,可能理解还不够准确,只能靠后续不断纠正了。
1、什么是POJO ?
POJO(Plain Old Java Object)这种叫法是Martin Fowler、Rebecca Parsons和Josh MacKenzie在2000年的一次演讲的时候提出来的。
按照Martin Fowler的解释是“Plain Old Java Object”,从字面上翻译为“纯洁老式的Java对象”,但大家都使用“简单java对象”来称呼它。POJO的内在含义是指:那些没有继承任何类、也没有实现任何接口,更没有被其它框架侵入的java对象。
先给一个定义吧:
POJO是一个简单的、普通Java对象,它包含业务逻辑处理或持久化逻辑等,但不是JavaBean、EntityBean等,不具有任何特殊角色,不继承或不实现任何其它Java框架的类或接口。 可以包含类似与JavaBean属性和对属性访问的setter和getter方法的。
POJO(Plain Old Java Object)这个名字用来强调它是一个普通java对象,而不是一个特殊的对象。
2005年11月时,“POJO”主要用来指代那些没用遵从特定的Java对象模型,约定或框架如EJB的Java对象。
理想地讲,一个POJO是一个不受任何限制的Java对象(除了Java语言规范)。例如一个POJO不应该是
1. 扩展预定的类,如 public class Foo extends javax.servlet.http.HttpServlet { ...
2. 实现预定的接口,如 public class Bar implements javax.ejb.EntityBean { ...
3. 包含预定的标注,如 @javax.ejb.Entity public class Baz{ ...
然后,因为技术上的困难及其他原因,许多兼容POJO风格的软件产品或框架事实上仍然要求使用预定的标注,譬如用于更方便的持久化。
一般在web应用程序中建立一个数据库的映射对象时,我们只能称它为POJO。
正确官方理解思路:
我在做Java EE培训中,发现我的很多学生问我什么是POJO,后来我在写书的时候发现POJO这个概念无法回避。现在网上对于POJO的解释很多,但是很多都是有错误的或者不够准确。
对此我一开始也是存在误区的,我原来是这样理解的: POJO是这样的一种“纯粹的”JavaBean,在它里面除了JavaBean规范的方法和属性没有别的东西,即private属性以及对这个属性方法的public的get和set方法。我们会发现这样的JavaBean很“单纯”,它只能装载数据,作为数据存储的载体,而不具有业务逻辑处理的能力。所以下面的代码被认为是POJO了。
-
package com.demo.spring;
-
public class DbHello implements Hello { //实现了接口,就不能称之为POJO,这已经不是简单的Java类了
-
private DictionaryDAO dao;
-
public void setDao(DictionaryDAO dao) {
-
this.dao = dao;
-
}
-
}
其实,这样的认为是错误的,我仔细阅读了《POJOs in Action》这本书的有关部分和POJO的最原始的出处http://martinfowler.com/bliki/POJO.html,The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000.
In the talk we were pointing out the many be