In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >
Share
Shulou(Shulou.com)06/01 Report--
This article will explain in detail what the core data in DTO service implementation is. The content of the article is of high quality. Therefore, Xiaobian shares it with you as a reference. I hope you will have a certain understanding of relevant knowledge after reading this article.
In a Web service implementation, we often need to access a database and display the data retrieved from the database in a user page. One problem with this is that the data used for presentation on the user page is often quite different from the data retrieved from the database. In this case, we often need to send multiple requests to the server to assemble the data for presentation on the page.
One way to solve this problem is to use different data representations based on different needs. Common data representations in a service implementation are MO (Model Object, also called VO in some contexts) and DTO (Data Transfer Object). MO is used to represent data read from a database, while DTO is used to represent data transmitted over the network.
We'll discuss how to use DTO and MO in a Web service implementation and briefly introduce other related data representations, such as View Models.
Why DTO?
Whether it is a desktop application or a Web service of a website company, its internal data performance is very important. When a beginner understands a system, he or she first needs to understand the role of the various components in the overall system, and then understand Workflow in the system, that is, how the various components work together when executing business logic. After understanding these two parts, all the beginner needs to do is comb through how the data flows through the system in detail, that is, organize and understand the process of data flow. After really understanding the data flow, the beginner has the ability to develop in the system.
The process of organizing the data stream is a gradual refinement process: from identifying the data structure to how exactly each attribute in the data structure is used. A change in the value of any one attribute throughout the data stream may result in a change in how the data is processed.
What do we do when we sort out the data stream? First, we need to identify what data is being transferred between components, what transformations are being made in the process, how the data is constructed, what data is constructed from it, whether the data is finally persisted to local storage, and so on.
In the process of organizing the data flow, the transformation of the data is often the most difficult part to understand. The definition of a data type is often dependent on the environment in which it operates. For example, in an e-commerce website, a class representing a product may contain all the information about the product: the name, brand, details, price, etc. of the product. This information will be displayed on the page when the user browses using a computer browser. However, when users use mobile phones to browse, we need to consider how to save traffic for these mobile phone users. One way to save users 'mobile traffic is to display brief information about the item first, and then download the details from the service when the user decides to check the details of the item. In this case, the class Product, which contains all the information about the item, would no longer be a suitable data structure for transmission.
The problem is not only in cases where data structures need to be split, but more likely in cases where data is consolidated. For example, in order to improve the user experience, the UE of the web page requests that the detailed information of the product brand be directly displayed on the page in the product page. In this case, we need to add a field brand to the class Product that represents the product. However, in the database, the class Product representing a commodity may only record the ID of the commodity brand. Therefore, in the business logic, we need to merge Product and its corresponding Brand together.
We can even make things more complicated:
We show how data can take many different forms in a system. In the center of the picture is a server from which a variety of clients will get product information. As mentioned above, in order to save client traffic, the data sent by the server to the mobile client will be a simplified version of the product information in the server. When a browser accesses the product, information indicating the product brand will be embedded in the product information to provide a better user experience. In addition to communicating with clients, servers may also exchange information. In this exchange, Product, which represents the product, and Brand, which represents the brand, are passed between the servers independently of each other. For a remote Agent, it may only need a Product ID to monitor the status of the product in production.
All this data should be obtained from the database of the system. It is impossible for data in a database to store and maintain this series of data structures at the same time, so in a complex system, there are often different data structures between the data represented in the database and the data transmitted in the system. A common situation is to divide it into two categories: one is used to access the database and represent the data recorded in the database in the system, called MO, i.e. Model Object; the other is used to transmit in the network, called DTO, i.e. Data Transfer Object.
DTO and MO in service
Now that we understand why we need different representations of data such as DTO and MO, let's look at how these data representations work in a Web service.
Let's start with the simplest Web service layering. One of the simplest Web services is divided into three parts: the data access layer (DAL), the business logic layer, and the presentation layer. The presentation layer runs on the client side, while the other two layers run on the server side. When the data is read from the DAL layer, the recorded data is consistent with the data recorded in the database, so they are the MOs we discuss in this article. When transmitted to the client, these data may be different from MO, so it is DTO:
Now let's zoom in on the data access layer to see where MOs are located in the data access layer:
First of all, it should be emphasized that there are many ways to implement the data access layer, and the above figure shows only one implementation based on the Repository pattern. Implementing DAL through Repository is one of the most common data access layer implementations. As shown in the figure above, in a Repository pattern-based implementation, the data access layer will have a series of Repository instances. These Repository instances rely on the ORM used by the system to convert data in the database into Java class instances. These Java class instances are actually MOs provided to the business logic layer at the data access layer.
DTO is used to transfer data between services and customers and between services. The requirements for DTOs in these delivery processes can be varied: Product is the type of DTO that interacts between the server and client and between the server. In this process, the DTOs that need to be passed are not the same: there may be slight differences in the way the data is presented when using a browser to read and save information about the Product. After saving, the service may send requests to other servers using the new Product as a payload, and the representation of the Product may be slightly different from the first two. If many different DTOs are defined for these nuances, the system's management of the data can run into a series of headaches. For example, in a complex system, DTO may flow through the system in the following manner:
In the figure above, we show a DTO flowing through multiple services in turn. If different DTO representations are used in the DTO sequence, the DTO required by one service may not match the DTO owned by another service. This is the simplest example of how DTO in turn affects architectural design, but it is also the most common problem in DTO management, which is that DTO has too many manifestations. If you create a DTO for all the different requirements, then there may be as many as 5 or 6 DTOs for a concept, which is very difficult to manage. This administrative difficulty often exists in specifying the type of DTO that a service needs to use, and in cases where a series of DTOs need to be modified simultaneously when a DTO is changed.
In order to prevent DTOs from spawning too many types due to different requirements, service implementations often allow data in DTOs to contain some redundancy.
Gradually add your DTO
So how do we add DTOs to the system? The answer is, it depends. At the beginning of the project, the data stored in the database is often consistent with the data that the page needs to display, so we don't need DTO help in this case. When the required data is no longer the same as the data recorded in the database, we need to consider whether to add DTO to the project. The software developer needs to ask himself: Is it common for the data needed to be inconsistent with the data in the database? If the answer is yes, then we need to start preparing to add support for DTO.
Adding DTO to the system mainly has the following parts to complete:
Add DTO class.
Add logic for conversion from MO to DTO.
Convert the original use of MO to the use of DTO.
The first thing readers notice is the third point. It is conceivable that if the MO of the whole system is replaced by DTO, its influence surface will be very large and it is very easy to make mistakes. Therefore, in a large project, we often need to prejudge the necessity of DTOs and add them early.
Let's go back and see how the first task should be done. In a system, DTO is often used to transmit data, so it often does not carry any logic of its own. This is why these DTOs are often defined as JavaBeans. Defining DTOs as JavaBeans has the great advantage that many third-party libraries provide JavaBean generation capabilities. In this case, software developers need only describe these DTOs in a set of descriptive languages. The most common of these is JAXB.
What is the core data in the DTO service implementation is shared here. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it so that more people can see it.
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.