Application Framework Design II: hierarchical and inter-layer data transfer (I)

Previous Article: Preface to Application Framework Design

Do you still remember the conflict between fat clients and thin clients that started around 97 years ago? Then there is a battle between CS and BS, and then a battle between two and multiple layers ..., ten years later, let's look back at these arguments. Everything seems to be so justified: How can programs not be layered? However, it took us ten years to reach a multi-layer consensus on a program architecture (low efficiency )!

To be layered, of course, it is basically three layers. In fact, the basis of multiple layers is also three layers: interface layer, business logic layer, and storage layer. Multiple Layers only split each layer more or less on the basis of the three layers. In general, there is no major change. The three layers are the basic concepts discussed in this series of articles.

This article focuses not on how to layer and how to define layers, but on how to transfer data between layers. Currently, the program seldom analyzes the data transmission problem between the layer and the layer. Generally, an object passes through the interface from the generation of the interface, save it directly to the database (the most notable mark is xxxID ). This method is very harmful to the program.

First, let's start with a simple example: Adding User features to an application. The interface is simple as follows:

 

Add User

Login Name
Password
Add User

 

It is usually very easy to design a data structure for this interface. class LoginInfo {public String name; public String password;} is fine, then, when the form is submitted, a new LoginInfo structure is added and loginInfo is saved to the database. The most common method is to add an int loginInfoID field. We name the data structure similar to LoginInfo that can be directly stored in the databasePersistence Object (PO for short). Well, it seems that there is no problem to use a data structure from the beginning to the end!

The problem may occur. bigtall is used to change the requirement. We usually need to enter the user password twice, so the interface is modified as follows:

Add User

Login Name
Password
Repeated input
Add User

In this way, the data structure submitted by form to the server should be like this: class LoginInfo2 {public String name; public String password; public String password2 ;}, then, the first thing the server does is to compare whether the password and password2 are equal, and then a new LoginInfo structure will fill in the name and password, and then save them to the database. We also modify the LoginInfo structure to the class LoginInfo {public int loginInfoID; public String name; public String password ;}.

As you can see, as the demand changes, the original "PO Express" has evolved into two structures. We call the data structure that is similar to the interface layer of LoginInfo2 and that of other layers to View Object, VO for short. Is that enough? Of course not. Let's modify the requirement and add the permission function to the system. Therefore, the added user should actually be modified as follows:

Add User

Login Name
Password
Repeated input
Administrator Department Manager Ordinary employee
Add User

We need to continue to make some improvements (or "refactoring"). First, we need to modify VO and standardize the name:

Class LoginInfoVO {public String name; public String password; public String password2; public String [] roles ;},

Split the previous LoginInfo into three classes:

Class LoginInfoBO {public String name; public String password; public RoleInfo [] roles ;}

Class LoginInfoPO {public int loginInfoID; public String name; public String password ;}

Class RoleInfoPO {public int loginInfoID; public String role ;}.

So far, we have successfully introduced three concepts: View Object (VO), Business Object (BO), and Persistence Object (PO ). They are the display layer, business logic layer, and Data structure used inside the storage layer. They are also collectively referred to as the Data Object (DO ). We can also regard VO, BO, and PO as different representations of DO at different stages. When a DO starts to traverse the entire system from the display layer, its form and structure begin to change, from VO to BO, and finally to PO, however, this process is not necessarily reversible. If this process is reversed from PO-> BO-> VO, it is likely to correspond to different objects. For example, when an input error occurs, an error message may be added to the feedback page. In actual use, we often ignore this subtle difference. In fact, this error message is only meaningful to the display layer.

The DO conversion rules can generally be summarized into the following types, and the actual changes can be combinations of various types:

• Attribute content reduction

The increase or decrease of attribute content often occurs during the transformation between different DO forms. For example, when adding the VO of the user LoginInfo object to BO in the above example, You need to discard the "repeated Password Input" attribute. Some VO objects do not even need to be converted to BO. When BO is converted to PO, attribute content will also be reduced, such as tree-level objects such as "departments", because of operational efficiency, you may need a "lower-level department list" in the BO. The PO only needs a "higher-level department ID" when it is actually stored in the database.

• Object content filling or adding

The property content may also increase. However, when the system processes DO conversions, adding the property may mean that additional queries and filling are required, for example, when we use the "user name" and "password" to log on, the system needs to query the database and store the "user ID" to ensure the uniqueness of the user. For example, if the submitted data has a verification error, we may need to refresh the page again and add the new attribute "ErrorMessage" to display it on the interface to remind users of the error.

• Object splitting and combination

Let's look at the last "Add User" example above. When a LoginInfo BO is converted to a PO, it is split into two objects, one storing basic user information, stores the corresponding Role information. When an object is split, it is often necessary to fill in or supplement the content of the new object. When the object is merged, the content is often reduced.

• Changes in object or attribute types

Changes in object property types are common in VO-BO conversion. For example, you can convert your input birthday to a real DateTime type.

• Attribute name changes

Attribute names may change during the conversion process. Generally, this case should not occur as much as possible, but it is more likely to happen during project reconstruction.

In addition to the conversion rules between different DO forms, there are also different tasks to be done within different forms:

• Verification

"Do not trust any user input" is a principle that will always be observed when the design program interacts with the user. That is, all external inputs must be verified for correctness. The validator is divided into two layers. One is the validation of the attribute level. For example, the "Age" can only be between 0 and 150. The other is object-level verification, or cross-Attribute-level verification. For example, "a year can be entered as a leap year, and may take 29 days on January 29, February.

Verification is not a simple problem. Almost all business logic verification requires a complete call throughout all layers. High cost. This is also why we perform a lot of pre-verification on the display layer. Once we enter the business logic layer, the validation is often replaced by "post-verification, people will use the method of throwing an exception to replace "pre-check ".

Suddenly I think there is a gossip to talk about. This analysis process was actually completed a year ago. At that time, the boiling SOA was full. After the DO form analysis, I looked back at SOA and found that it was not a performance layer, it belongs to the business logic layer. In other words, the DO used must be BO rather than VO. The so-called SOA is just a distributed business logic layer.

Because the following sections require a lot of time to search, bigtall is afraid that the article will be delayed for a long time, And bigtall will be afraid that you will wait too long for the official readers. In the next article, we will focus on the comparison between the existing architecture of the net platform and the java platform in the DO form. We will also discuss a practical question about whether the Object ID is required.

---

2009-8-12 correct DO's mistake in DTO.