Java数据对象和数据模型

发布于 2022-10-04  6.24k 次阅读


1. JavaBean,Entity,Modle

1.1 JavaBean

javaBean是一种特殊的java类:

  • javaBean主要用于定义一组规则
  • javaBean本质上就是遵循规则的普通java对象

简单地说,JavaBean是用Java语言描述的软件组件模型,其实际上是一个类。这些类遵循一个接口格式,以便于使函数命名、底层行为以及继承或实现的行为,可以把类看作标准

JavaBean是相比较与其他两种概念最早出现的,在J2EE时代有其的完整化定义 

JavaBean的分类

  • 可视化Bean组件:可视化组件可以是简单的GUI元素,如按钮或文本框,也可以是复杂的,如报表组件
  • 非可视化Bean组件:没有GUI的表现形式,主要用于封装业务逻辑,数据库逻辑等

注:在现在的java开发中主要是以非可视化Bean组件为主,Java GUI开发在现开发中已经被淘汰

Ⅰ 使用JavaBean的原因

    程序开发往往有重复使用的代码片段,javaBean就是为了能够复用而设计出来的程序段落,而且这些代码片段并不只服务于某一个程序,而且每一个JavaBean都有具有特定功能,当需要这个功能的时候就可以调用相应的JavaBean,这样大大简化了程序的设计过程,也方便了其他程序的重复使用

Ⅱ JavaBean的开发

    在程序设计过程中,JavaBean不是独立的,为了能够更好的封装业务逻辑,数据库操作而实现业务逻辑和前台程序的分离,操作的过程往往是先开发需要的javaBean,再在适当的时候进行调用,但一个完整有效的javabean必然会包含属性,伴随若干个get/set(只读/只写)函数的变量来设计和运行的

javaBean的书写特定:

  1. 这个java类必须具有一个无参的构造函数
  2. 属性必须私有化
  3. 实现java.io.Serializable 接口
  4. 通过getter/setter方法访问

Ⅲ JavaBean的优点

  • 易于维护、使用、编写。
  • 可实现代码的重用性。
  • 可移植性强,但仅限于Java工作平台。
  • 便于传输,不限于本地还是网络。
  • 可以以其他部件的模式进行工作

1.2 Entity

Entity的含义是实体,包含数据实体和业务实体

Entity包中的类是必须和数据库相对应的,比如:比如说:数据库有个user表,字段有long类型的id,string类型的姓名,那么entity中的user类也必须是含有这两个字段的,且类型必须一致。不能数据库存的是long类型,user类里的属性是string类型。这样做的好处是保持实体类和数据库保持一致

在用到Hibernate或Mybatis框架来操作数据库的时候,操作这个实体进就行

数据实体的含义:

  • 对对象实体的封装,体现OO思想。
  • 属性可以对字段定义和状态进行判断和过滤
  • 把相关信息用一个实体类封装后,我们在程序中可以把实体类作为参数传递,更加方便
  • 就是一个数据库表生成一个类

实体的编写规范:

  • 实体类的名字尽量和数据库的表的名字对应相同。
  • 实体类应该实现java.io.Serializable接口。
  • 实体类应该有个无参的构造方法。
  • 实体类应该有个有参(所有的参数)的构造方法。
  • 实体类有属性和方法,属性对应数据库中表的字段,主要有getter和setter方法。
  • 实体类还应该有个属性serialVersionUID。例如:private static final long serialVersionUID = -6125297654796395674L;
  • 属性一般是private类型,方法位public类型,对于数据库自动生成的ID字段对应的属性的set方法应为private

1.3 Modle

Modle的含义是模型,模型包括数据模型和业务数据

Modle包中一般存的是实体类的模型,这些模型实体供前端使用,后台从数据库取了数据转化为前端需要的数据直接传给前端,前端就不需要对数据来处理,直接显示就行了。还有一种情况,数据库里面的user表字段有十个,包含姓名,qq,生辰八字乱七八糟的等,但是前台页面只需要显示姓名,如果把entity全部传给前台,无疑传了很多没用的数据。这时候model就很好的解决了这个问题,前台需要什么数据

注:Entity和Modle本质上都属于JavaBean,只是按不同的使用场景下做的区别,介于service和数据库DAO就行转换的就属于Entity,介于Controller和前端数据的交互就属于Modle

2. DO,BO,DTO,VO

实体(Entity)和模型(Modle)可以泛指任何事物:如数据实体、业务实体、数据模型、业务(领域)模型。但它们不能在开发中明确的表述某一领域,所以需要在具体的业务场景中对他做进一步的区别,所以就产生了PO、DTO、VO等概念

例:一个用户实体属于Entity,当它在不同的业务操作过程中可以叫UserPojo,UserDao,UserDto,UserVO等

注:这些分类并不是一定的,不同的公司对这些名词有自己的定义,但定义的逻辑是一样的

① DO

DO:Date Object即数据对象,产与数据表相对应,通过DAO层向上传输数据

在DDD领域驱动模型中,DO也可以称为Domain Object即领域对象

在Java开发中通常属于dao、bean、entity、modle等作为包名。以DO做为结尾,如:StudentDO

② BO

BO:Business Object即业务对象,通过Sercive层向上传输数据

例:数据库中有商品表(GoodsDO -> id/name/介绍/单价)和订单表(OrderDO -> 用户/发货时间/……)。

现在需要关联查询GoodsDO和OrderDO信息展示给用户,但不同视角下数据模型和业务模型是不同的,这个时候新建一个业务对象就行合并。GoodsBO(用户/发货时间/介绍/单价……)

③ VO

VO:View Object 表示层对象,通过接口向前端输出展示的对象

VO在功能上等价与BO,也可以是BO的聚合,它主要是向前端返回数据时对象

在商品表(GoodsDO)和订单表(OrderDO)我们向前端展示的时候不想要携带用户ID/预售日期等数据时。则可以聚合抹除这些数据创建一个新的VO对象进行返回

④ DTO

DTO:Date Transder Object数据传输对象

主要应用于web ->Service, Service -> dao层的数据转换

一般DTO指入参数对象

⑤ POJO

POJO(或PO):Plain Ordinary Java Object,代表普通的Java对象

⑥ 其他对象

  • Req:请求对象
  • Resp:响应对象
  • Query:查询对象
  • ……

各层调用关系图:

命名规范:非绝对,仅提供参考

命名规范
含义
XxVo
展示层对象命名
XxDto
数据传输层对象命名
XxBo
Service业务对象命名
XxDo
数据库实体对象命名
XxIndexDo
ElasticSearch实体对象命名
XxDoc
mongo实体对象命名
XxService
Service接口命名
XxServiceImpl
Service接口实现命名
XxMapper
Dao层命名
XxRespository
封装持久化组合响应服务对象

路漫漫其修远兮,吾将上下而求索