Hippo technology inside ASP. NET open-source framework (II)-meta-data driver

Ii. Meta-data driver

In the previous chapter, I introduced the hippo System in the general direction and started from this chapter.

To better organize the system structure, all basic information is extracted and stored in the database. This method is learned from BroadVision.

To store such data, you need to store several different types of objects, as shown below:

Object	table name	meaning
schema	zr_schema	mode
content	zr_content	content
table	zr_tables	table corresponding to the mode
attribute	zr_attribute	description of all fields in each table

In the above expression, schema is the bottom layer of the entire meta-data structure, and all information must be attached to it. So what is schema? literal translation is "schema ", all the content descriptions in the system should end with schema expressions, such as "news", "user", and "product, that is to say, similar content belongs to a schema.

Content is the meaning of content. According to CMS, it should be an important layer. Yes, in this system, content is actually an extension of schema, it has more attributes, and the schema and content must correspond one to one. If possible, it can be understood that the two attributes belong to the same part. In actual application, I have also made some triggers. When I modify the content, I will modify the associated schema at the same time. Someone will ask, why should I divide it into two parts for storage, I wanted to completely learn the BroadVision method, but it was simplified at last.

Table is easier to understand. It does not have the abstraction and mystery of the above two objects. It is used to describe the tables used to store data, in relational databases, no matter what the performance layer is, data must be stored in a specific table. The relationship between Shema and table is one-to-many, that is, the same content can be stored in multiple tables. For example, the "user" mode is divided into several main tables, one is zr_user, which stores several basic fields such as member ID, member region number, and password. The zr_user_profile table stores user extended attributes, such as member name and birthday, ID card, etc. When used, adding two tables can be equivalent to one table. This data storage method is totally different from writing all the fields of a user into a table. In fact, there is no difference between good and bad, the main difference is that when the data volume is large, my design method puts less pressure on the database, because when logging on, you only need to check a few limited fields, even if you perform a full table description, it will take up less Io operations. The third type of table is "sub-table". I will give the sub-table an example. A member can have multiple email addresses. If you put all these fields in one table, we need to reserve multiple fields. Therefore, we need to create a separate table and then use a foreign key to correspond to the user table to express the one-to-many relationship between the user and the email, during front-end display, this one-to-multiple sub-table is presented in a special way.

Attribute is easier to understand. It is actually a field in the database. That is to say, the descriptions of the fields corresponding to the table above are stored in this table. Why not use column? Because attribute is more object-oriented and feels like a database, there is no difference.

In fact, a system table can be found in any database, which stores the field descriptions corresponding to each table. Why do we need to create a dedicated table for repeated storage? It is shown that the information stored by the system is completely DB's own information and cannot be extended, and the storage methods of each database are also different. Therefore, it is extracted separately.

In the system, four classes are developed to describe the above four tables. In addition, the classes of two managers are also created to manage the above classes, as shown below:

Schemamanager

Contentmanager

You can use these two managers to create a new schema or modify an existing content. In short, the idea of all this work is to try to reduce the direct dealings between users and databases and encapsulate all the operations. It is more object-oriented.

It is worth talking about here. When using objects, the attributes of objects are written.ProgramFixed, such as the height and weight of members. These fixed attributes will not change with customization, but the tables in the database may change significantly in the customization process, so how can we ensure that they can correspond smoothly when using the object description? My approach is to find several fixed fields to form class attributes, such as the login name and password, while the name, ID card and other information. In the user class, no corresponding attribute is found. Instead, all these attributes are placed in a large hashtable to form a composite attribute, the name is properties, so you can reference it as follows

User. useralias is the user's login name

User. properties ["name"] is the member's name

It can be seen from the above that no matter how many extensions are made to the attribute, this method can be used for good presentation.

We will discuss the storage and usage of users' passwords in a special chapter later.

Here is an example of how to extract all the news:

If the content of the news is named editorial, the program can write as follows:

Contentmanager = new contentmanager ("editorial ");

Datatable table = contentmanager. getcontent ();

As long as the above two simple descriptions are used, all the news can be taken out and put into a datatable for backup. Later, you can use it to directly fill in the DataGrid.

In many cases, you do not need to extract all the news. In this case, you need to perform a filter condition, or retrieve the first 10 news, or sort by a field. For all these functions, have been configured for contentmanager. the getcontent () function carries out a variety of overload operations, as long as appropriate parameters are added, due to limited space, it cannot be described one by one.

I have heard that meta-data is always abstract, and I don't know what I want to do or what I want to do. However, meta-data is the core idea of the system, even if you do not read the subsequent chapters, it will be of great help to your future design. Starting from the next part, some key operations will be performedCode.