本篇文章给大家谈谈javaentity转dto，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
1、javaweb项目中entity,model,dto，domain分别在什么情况下用？2、Java 的DTO的作用到底是干什么的？3、java xml 转 dto的实例4、java 中entity 实体类是将前台数据传过来还是将数据库中数据传过来，一直不理解求指教5、java项目中VO和DTO以及Entity，各自是在什么情况下应用的？
javaweb项目中entity,model,dto，domain分别在什么情况下用？
entity属于实体类，与数据库表一一对应，model属于mvc里面m，dto是根据实际业务创建的类，用于存放数据，domain是学校类
Java 的DTO的作用到底是干什么的？
首先dto和实体变量的名字和个数应该是一模一样的（Dto可以都是String类型或类型也和实体一样），dto只在数据存储时有用，开发的规范是将要存储的数据以dto存到数据库。
如：前台页面提交的form表单，后台接收到，转换成dto，存入数据库。
你说的：‘’只是为了把查询出实体的值在通过get set转到DTO“ 这是不对的，这是没意义的。特殊情况下如：前台页面提交的form表单的值不够，还需要再查询别的表，然后转成dto，才可能需要你说的get set几个值。
java xml 转 dto的实例
在一个Web服务的实现中，我们常常需要访问数据库，并将从数据库中所取得的数据显示在用户页面中。这样做的一个问题是：用于在用户页面上展示的数据和从数据库中取得的数据常常具有较大区别。在这种情况下，我们常常需要向服务端发送多个请求才能将用于在页面中展示的数据凑齐。
一个解决该问题的方法就是根据不同需求使用不同的数据表现形式。在一个服务实现中较为常见的数据表现形式有MO（Model Object，在有些上下文中也被称为VO，Value Object）和DTO（Data Transfer Object）。MO用来表示从数据库中读取的数据，而DTO则用来表示在网络上所传输的数据。
在本文中，我们将讨论如何在一个Web服务的实现中使用DTO及MO，并会对其它一些相关数据表现形式，如View Model等进行简单地介绍。
Why DTO?
无论是桌面应用还是Web服务，其内部的数据表现都是非常重要的。在一个初学者了解一个系统的时候，其首先需要了解整个系统中的各个组件的作用，然后再了解系统中的Workflow，即在执行业务逻辑时各个组件是如何协同工作的。在了解了这两部分之后，该初学者需要做的事情就是详细地梳理一遍数据是如何在整个系统中流动的，即是整理并理解数据流（Dataflow）的过程。而在真正理解了数据流后，该初学者才具有了在系统中开发的能力。
整理数据流的过程是一个逐步细化的过程：从鉴别数据结构到该数据结构中的每个属性到底是如何使用的。在整个数据流中，任何一个属性值的改变都可能会导致数据的处理方式发生变化。
在整理数据流的时候我们要做什么样的事情呢？首先我们需要鉴别出到底哪些数据会在各个组件之间进行传送，在传送过程中进行了什么样的转化，这些数据是如何构建出来的，又由它构建了哪些数据，最终这些数据是否被持久化到了本地存储中等等。
而在整理数据流的过程中，数据的转化常常是最难理解的部分。一个数据类型的定义常常与其运行环境有关。例如在一个电子商务网站中，一个表示商品的类Product可能包含了该商品的所有信息：商品的名称，品牌，详细介绍，价格等。在用户使用电脑浏览器浏览的时候，这些信息都将被显示在页面上。但是在用户使用手机进行浏览时，我们就需要考虑如何为这些手机用户节省流量的问题。一种节省用户手机流量的方法就是首先显示商品的简略信息，并在用户决定查看商品的详细介绍时再从服务端下载商品的详细信息。在这种情况下，包含商品所有信息的类Product将不再是适合传输的数据结构。
而问题不仅仅出在需要将数据结构拆分的情况下，更可能出现在数据合并的情况中。例如网页的UE为了提高用户体验，要求在产品页面中直接将该商品品牌的详细信息显示在页面中。在这种情况下，我们就需要在表示商品的类Product中添加一个记录该商品品牌的域brand。但是在数据库中，表示商品的类Product可能仅仅记录了商品品牌的ID。因此在业务逻辑中，我们就需要将Product和其对应的Brand合并在一起。
甚至说，我们可以将事情弄得更复杂一些：
在上面的图中，我们展示了数据在一个系统中可能存在的多种不同表现形式。在图片的中央位置的是一个服务器，多种客户端都将从它那里获得产品信息。就像前面所说，为了节省客户端的流量，服务端向移动客户端所发送的数据将是产品信息在服务端中的简略版本。而在一个浏览器访问该产品的时候，表示商品品牌的信息将内嵌在产品信息之中，以提供更好的用户体验。除了与客户端通讯，服务端之间也可能产生信息的交换。在该交换过程中，表示产品的Product以及表示品牌的Brand则彼此独立地在服务端之间传递。而就一个运行在远端的Agent而言，其可能仅仅需要一个Product的ID来监控产品在生产制作方面的状态。
而这一切数据都应当从系统的数据库中得到。数据库中的数据不可能同时存储并维护这一系列数据结构，因此在一个复杂的系统中，数据库中的数据表示与系统中所传输的数据之间常常是不同的数据结构。常见的情况则是将其分为两类：一类用来访问数据库，在系统中表现数据库中所记录的数据，叫MO，即Model Object；另一类用来在网络中传输，叫DTO，即Data Transfer Object。
服务中的DTO和MO
在了解了我们为什么需要DTO和MO等数据的不同表示之后，就让我们来看看这些数据表示在一个Web服务中是如何工作的。
先让我们从最简单的Web服务分层开始说起。一个最简单的Web服务主要分为数据访问层（DAL），业务逻辑层以及表现层三个部分。其中表现层是运行在客户端的，而其它两个层次则运行在服务端。当数据从DAL层读取出来的时候，其所记录的数据与数据库中所记录的数据是一致的，因此它们就是我们这篇文章中讨论的MO。而在传输给客户端的时候，这些数据可能会和MO不同，因此其为DTO：
现在就让我们放大一下数据访问层，来看看数据访问层中MO所在的位置：
首先要强调的是，实现数据访问层的方式有很多种，而上图所展示的仅仅是一种基于Repository模式的实现。通过Repository来实现DAL是一种最为常见的数据访问层实现方式。就像上图所展示的那样，在一个基于Repository模式的实现中，数据访问层将拥有一系列Repository实例。这些Repository实例依赖于系统所使用的ORM来将数据库中的数据转化为Java类实例。这些Java类实例实际上就是在该数据访问层所提供给业务逻辑层的MO。
而DTO则用于在服务与客户之间以及服务和服务之间进行数据的传递。在这些传递过程中，对DTO的需求可能是多种多样的：
上面的图片展示了一段Product这种类型的DTO在服务端和客户端以及服务端之间进行交互的过程。在该流程中，所需要传递的DTO并不相同：在使用浏览器读取和保存有关Product的信息时，两者的数据表现形式可能会有一些细微的差别。而在保存完毕后，服务可能会将新的Product作为负载来向其它服务器发送请求，而此时所使用的Product的表示又可能与前两种略有差别。如果为这些细微的差别定义很多不同的DTO，那么系统对数据的管理可能会遇到一系列麻烦。例如在一个复杂的系统中，DTO可能会按照下面的方式在系统中流转：
在上图中，我们展示了一个DTO在依次流转过多个服务的情况。如果在DTO依次传递的过程中使用了不同的DTO表示，那么一个服务所需要的DTO可能和另一个服务中所拥有的DTO并不匹配。这便是DTO反过来会影响到架构设计的一个最简单的例子，却也是DTO管理中最常见的问题，那就是DTO的表现形式过多。如果为所有的不同需求都创建一个DTO，那么一个概念所对应的DTO可能多达5，6种，非常难于管理。这种管理上的困难常常存在于如何指定某个服务所需要使用的DTO种类，以及在更改DTO时需要同时修改一系列DTO的情况中。
为了防止DTO由于不同的需求而衍生出过多的种类，服务实现中常常允许DTO中的数据包含一些冗余。
逐步添加你的DTO
那么我们该如何向系统中添加DTO呢？答案是，根据情况决定。在项目的一开始，数据库中所存储的数据与页面所需要显示的数据常常是一致的，因此在这种情况下，我们并不需要DTO的帮助。而在所需要的数据和数据库所记录的数据不再一样的时候，我们就需要考虑是否需要在项目中添加DTO了。这时软件开发人员就需要问自己：这种所需要的数据与数据库中的数据不一致的情况是否常常出现？如果答案是“是”，那么我们就需要开始着手准备添加对DTO的支持。
在系统中添加DTO主要有以下几部分工作需要完成：
添加DTO类。
添加从MO到DTO的转化逻辑。
将原本对MO的使用转换为对DTO的使用。
相信读者最先注意到的就是第三点。可以想象到的是，如果将整个系统的MO替换成DTO，那么它的影响面将会非常大，而且非常容易出错。因此在一个大型项目中，我们常常需要预先判断DTO的必要性，进而尽早地添加DTO。
让我们回过头来看看第一个任务应该如何完成。在一个系统中，DTO常常用来传输数据，因此其自身往往不带有任何逻辑。这也便是这些DTO常常被定义成JavaBean的原因。以JavaBean的形式来定义DTO带来了一个巨大的好处，那就是很多第三方类库都提供了生成JavaBean的功能。在这种情况下，软件开发人员只需要通过一系列描述性语言来描述这些DTO即可。这其中最常用的便是JAXB。
附上出处链接：
java 中entity 实体类是将前台数据传过来还是将数据库中数据传过来，一直不理解求指教
其实都有，而且可能有好多名字什么dto,vo等等，其实本质是一样的，就是把数据重新组装成更方便使用的JAVA对象而已。比如前台表单出来的参数a=1b=2酱紫就不好操作，然后封装成一个对象o，你用的时候就可以o.a ,o.b这样操作了，比较方便
java项目中VO和DTO以及Entity，各自是在什么情况下应用的？
你好，按照标准来说：
1、entity里的每一个字段，与数据库相对应，
2、dto里的每一个字段，是和你前台页面相对应，
3、VO，这是用来转换从entity到dto，或者从dto到entity的中间的东西。
举个例子：
你的html页面上有三个字段，name，pass，age
你的数据库表里，有两个字段，name，pass(注意没有age哦)
而你的dto里，就应该有下面三个(因为对应html页面上三个字段嘛)
private string name；
private string pass;
private string age;
这个时候，你的entity里，就应该有两个(因为对应数据库表中的2个字段嘛)
private string name；
private string pass;
到了这里，好了，业务经理让你做这样一个业务“年龄大于20的才能存入数据库”
这个时候，你就要用到vo了
你要先从页面上拿到dto，然后判断dto中的age是不是大于20，如果大于20，就把dto中的
name和pass拿出来，放到vo中，然后在把vo中的name和pass原封不懂的给entity，然后根据
entity的值，在传入数据库，这就是他们三个的区别
PS，VO和entity里面的字段应该是一样的，vo只是entity到dto，或者dto到entity的中间过程，如果没有这个过程，你仍然可以做到增删改查，这个就根据具体公司来的，纯手打，望采纳
关于javaentity转dto和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
微信扫一扫 
支付宝扫一扫 
