这篇文章将为大家详细讲解有关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。
关于DTO服务实现中的核心数据是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
