工作总结:mvc分层架构

发布于:2021-10-17 01:02:31

pojo:plain?ordinary?java?object?简单无规则java对象,我个人觉得它和其他不是一个层面上的东西,VO和PO应该都属于它


po:persistant?object?持久对象,可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中某个表中的一条记录,多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作


do:domain object 领域对象 就是从现实世界中抽象出来的有形或无形的业务实体。一般和数据中的表结构对应


dao:data?access?object?数据访问对象,此对象用于访问数据库。通常和PO结合使用,DAO中包含了各种数据库的操作方法。通过它的方法,结合PO对数据库进行相关的操作


vo:value?object值对象。通常用于业务层之间的数据传递,和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.个人觉得同DTO(数据传输对象),在web上传递


bo:business?object?业务对象,封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作


VO(View Object):视图对象,用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。

VO与DTO的区别

VO与DTO的应用

以下场景需要优先考虑VO、DTO并存:

DTO与DO的区别

DTO与DO的应用

对于DTO来说,也有一点必须进行说明,就是DTO应该是一个“扁*的二维对象”,举个例子来说明:如果User会关联若干个其他实体(例如Address、Account、Region等),那么getUser()返回的UserInfo,是否就需要把其关联的对象的DTO都一并返回呢?如果这样的话,必然导致数据传输量的大增,对于分布式应用来说,由于涉及数据在网络上的传输、序列化和反序列化,这种设计更不可接受。如果getUser除了要返回User的基本信息外,还需要返回一个AccountId、AccountName、RegionId、RegionName,那么,请把这些属性定义到UserInfo中,把一个“立体”的对象树“压扁”成一个“扁*的二维对象”,笔者目前参与的项目是一个分布式系统,该系统不管三七二十一,把一个对象的所有关联对象都转换为相同结构的DTO对象树并返回,导致性能非常的慢。




DO与PO的应用

简单来说:


在代码中 vo(值对象)dto do 都是对应实体的可以看做是之前是entity


bo 是操作单表 service是操作多表 service 可以调用bo(包含bo)


domain 相当于 controller


domain 暴露给用户做调用


?





---恢复内容结束---


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




轻灵划译


数据来源:




转载于:https://www.cnblogs.com/jack4738/p/8334106.html






相关资源:利用遗传算法解决矩形排样问题,具有可视化的界面 两个

相关推荐

最新更新

猜你喜欢