dto与数据库交互(dto是展示层的数据还是服务层的)

这篇文章会详细讲解DTO服务实现的核心数据是什么，文章内容质量很高，所以边肖会分享给大家参考，希望大家看完这篇文章有所了解。

在Web服务的实现中，我们经常需要访问数据库，并在用户页面上显示从数据库中获取的数据。这样做的一个问题是，用户页面上显示的数据和从数据库中获得的数据之间往往有很大的差异。在这种情况下，我们经常需要向服务器发送多个请求来收集数据以显示在页面上。

解决这个问题的一种方法是根据不同的需求使用不同的数据表示。服务实现中常见的数据表达式是模型对象(也称为VO、值对象)和DTO(数据传输对象)。MO用于表示从数据库中读取的数据，而d to用于表示网络上传输的数据。

我们将讨论如何在网络服务的实现中使用DTO和维护对象，并简要介绍一些其他相关的数据表达式，如视图模型。

Why DTO?

无论是长沙网站公司的桌面应用还是Web服务，其内部数据表现都非常重要。初学者在理解一个系统时，首先需要了解整个系统中各个组件的功能，然后了解系统中的Workflow，即执行业务逻辑时各个组件是如何协同工作的。了解了这两部分之后，初学者需要做的就是详细梳理一下data flow在整个系统中是如何流动的，也就是梳理和理解数据流的过程。只有真正理解了数据流，初学者才有能力在系统中开发。

整理数据流的过程是一个逐步细化的过程：从识别数据结构到如何使用数据结构中的每个属性。在整个数据流中，任何属性值的改变都可能导致数据处理方式的改变。

整理数据流的时候我们要做什么？首先，我们需要识别每个组件之间将传输哪些数据，在传输过程中发生了什么样的转换，这些数据是如何构造的，它构造了什么数据，这些数据是否持久化在本地存储中等。

在梳理数据流的过程中，数据转换往往是最难理解的部分。数据类型的定义通常与其运行环境相关。例如，在电子商务网站中，代表商品的产品类可能包含商品的所有信息：名称、品牌、详细介绍、价格等。当用户使用计算机浏览器浏览时，此信息将显示在页面上。但是当用户使用手机浏览时，我们需要考虑如何为这些手机用户节省流量。一种节省用户手机流量的方法是先显示产品的简要信息，当用户决定查看产品的详细介绍时，再从服务器下载产品的详细信息。在这种情况下，包含商品所有信息的产品类将不再是适合传输的数据结构。

问题不仅在于何时需要拆分数据结构，还在于何时需要合并数据。例如，为了提高用户体验，网页的UE要求在产品页面中的页面上直接显示产品品牌的详细信息。在这种情况下，我们需要在代表产品的产品类中添加一个记录产品品牌的领域品牌。但是，在数据库中，代表商品的Product类可能只记录商品品牌的ID。因此，在商业逻辑上，我们需要将产品与其对应的品牌结合起来。

甚至，我们可以让事情变得更复杂：

我们展示了系统中可能存在的各种不同形式的数据。图片的中央是一个服务器，各种客户可以从中获取产品信息。如前所述，为了节省客户端的流量，服务器发送给移动客户端的数据将是服务器中产品信息的简要版本。当浏览器访问产品时，指示产品品牌的信息将被嵌入产品信息中，以提供更好的用户体验。除了与客户端通信之外，服务器之间也可能发生信息交换。在这个交换过程中，代表产品的产品和代表品牌的品牌在服务器之间相互独立地传递。就远程代理而言，它可能只需要产品的标识来监控产品的生产状态。

所有这些数据都应该从系统的数据库中获得。数据库中的数据不可能同时存储和维护这一系列数据结构，因此在复杂系统中，数据库中的数据表示和系统中传输的数据之间的数据结构往往是不同的。一般来说分为两类：一类是用来访问数据库的，表示系统中数据库记录的数据，称为MO，即Model Object；另一种类型用于网络中的传输，称为DTO，即数据传输对象。

服务中的DTO和MO

在理解了为什么我们需要DTO和维护对象数据的不同表示之后，让我们来看看这些数据表示在网络服务中是如何工作的。

让我们从最简单的网络服务分层开始。最简单的Web服务主要分为数据访问层(DAL)、业务逻辑层和表示层。表示层在客户机上运行，而另外两层在服务器上运行。当从DAL层读取数据时，记录的数据与数据库中记录的数据一致，因此它们是本文中讨论的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主要有以下几部分工作需要完成：

1. 添加DTO类。

2. 添加从MO到DTO的转化逻辑。

3. 将原本对MO的使用转换为对DTO的使用。

　　相信读者最先注意到的就是第三点。可以想象到的是，如果将整个系统的MO替换成DTO，那么它的影响面将会非常大，而且非常容易出错。因此在一个大型项目中，我们常常需要预先判断DTO的必要性，进而尽早地添加DTO。

　　让我们回过头来看看第一个任务应该如何完成。在一个系统中，DTO常常用来传输数据，因此其自身往往不带有任何逻辑。这也便是这些DTO常常被定义成JavaBean的原因。以JavaBean的形式来定义DTO带来了一个巨大的好处，那就是很多第三方类库都提供了生成JavaBean的功能。在这种情况下，软件开发人员只需要通过一系列描述性语言来描述这些DTO即可。这其中最常用的便是JAXB。

关于DTO服务实现中的核心数据是什么就分享到这里了，希望