Entity definition: each layer is different. Some Thoughts on ing between layer entities

Entity Relationship Diagram is one of the things we must do when designing. Many people are using UML, but entity relationship diagram is still an indispensable and effective data analysis method.

When it comes to the object relationship diagram, many people immediately think of the database, and so do I. In practice, we often need to consider ing the table structure in the database to the data structure, and then use code similar to the following to complete our work:

// The code of the last century, pseudocode
DBCommand command = GetSQL ("select * from xxx where ");
String name = command. GetString ("Name ");
Int age = command. GetString ("Age ");


// This century's code, pseudocode
Class HumanInfo
{
String Name;
Int Age;
}

HumanInfo info = (HumanInfo) nhib.pdf. Load ();

But have you found out that the data structure used is basically one-to-one correspondence with the table structure, so we sometimes get complicated to use, such as getting a friend's name, we may use this code: FindPeople (man. friendID ). name. In fact, if you do not consider the database, the best method may be like this: man. BestFriend. Name. Why can't we let ourselves define the data structure in the most efficient way?

This is what we need to talk about in this article, but I am not thinking deeply. So I hope you can come and talk with me.

Generally, an application can be divided into at least three layers: interface layer, business layer, and data layer. Our current object definition is basically only considered at the data layer, that is, the object definition is equivalent to the database table structure definition. But in fact, all three layers have different entity definition requirements. Let's take a simple "personal interpersonal relationship" example to see where the demand for entities varies at each layer.

1. Interface Layer

The main object of the interface layer is the user. The interface content that makes sense to the user includes the following:
Name, age, birthday, Region (province, city), email 1, email 2, email n, phone 1, Phone 2, phone n, last contact time, relationship networks (persons 1, persons 2, and persons n)

The program we added is intended for mass users. Therefore, we cannot display anything like code 0016 on the interface. If we can use Chinese characters, we should try to use Chinese characters for representation, for example, the region cannot be simply replaced by the telephone area code or postal code, and text such as "Changsha, Hunan" must be displayed.

More importantly, these users are different from programmers. They do not have the concept of "set" or "association". It is not appropriate to try to expose the concept to end users. The main consideration of the interface layer is expressiveness. "No ambiguity" and "clear view" are the goals it pursues.

2. Business Layer

The main contact with the business layer is programmers. For programmers who need meaningful content and their organization methods, the following definitions should be reasonable:

Public class People
{
Public string Name;
Public int Age;
Public DateTime Birthday;
Public AreaType Area;
Public MailBoxCollection MailBoxs;
Public DateTime LastComm;
Public PeopleCollection Relations;
}

Public class AreaType
{
Public int ID;
Public string Name;
}

The business layer needs to consider more problems than the interface layer. Here, we need to consider both usability and performance issues. For example, in the definition of PeopleCollection, you need to consider whether it contains a People or only a PeopleID. If you are not clear about these issues, it will cause a big problem for the interaction with the data layer.

3. Data Layer

The data layer must describe the database table structure, but it is not strictly consistent, but the abstraction should not be too large to avoid affecting efficiency. However, systems in China are generally customized, so many projects directly adopt the table structure definition as the entity definition of the data layer. The preceding simple definition becomes very huge at the data layer. I use the figure below:

As we can see from the above, because each layer faces different users, resulting in different layers of definition requirements for Entity Data. In actual use, due to various factors (project progress, budget, personnel capabilities, design intensity, etc.), we often intentionally or unintentionally ignore this difference. The consequence of ignoring the differences in entity requirements between layers is that we often intentionally or unintentionally bring our underlying concepts to users, let's take a look at the input boxes that are constantly popped up in our system (compare the office and exchange software of M $). Also, due to the limitations of the underlying data, some features cannot be continuously improved; the most terrible thing is that once the customer's needs change, the workload and difficulty from the beginning to the end often make us very afraid.

Is there any tool that makes it easy for us to do this? This may happen in the future, but the premise is that we need to find the rule of this data transformation. Chairman Mao said that he had to work on his own. Let's take a look at it on our own.

The first is the data transformation rule from the interface layer to the business layer. In this transformation process, the "dictionary ing" method accounts for a large proportion. For example, we need to change the content of the "region" from Chinese characters to an AreaType object, the goal is to reduce data duplication and redundancy and change disorder into order.

Second, data changes from the business layer to the data layer. In this change, the "join" method accounts for a large proportion. To facilitate programming, We have redundant a lot of data and put the data at the business layer to the data layer, you need to continue slimming.

When I wrote this article, I suddenly thought that the data conversion between the three layers is actually the conversion process of the first, second, and third paradigm of the database. It seems that you have to make up the course again.