CYQ. How does the lightweight Data layer Framework respond to database changes?

Someone posted a post in the group today: we welcome you to discuss the Model data entity layer.

Content:

How can we solve the following problems:

Model is the entity ing of database tables. When the system requires new transformations, such as adding new functions, the database needs to add new fields,
Or you need to remove and replace some old functions, the corresponding database fields will be modified. If the table structure of the database is changed,
The corresponding object Model layer must be transformed.

Change a field,
The Model layer must be modified,
The DAL layer must be modified,
The SQL statement must be modified,
The data presentation of the presentation layer is also dependent on the attribute name of the Model layer and must be modified.
This is not in line with the single responsibility of the design model. Start the whole body.
In this way, the design model is useless.
Second, the workload is very large. For example, if the commodity table is used, it is very difficult to simply execute the query.
How can we solve this problem or minimize the impact.

 

There are more than N posts under the post to discuss the problem, but there is no fundamental solution in essence, or as some people in the post said:

1: the root cause of the problem is: "Model is the entity ing of database tables", so all the resulting derivation is wrong.
2: The model is modified after the requirement is changed, not the database!
3: A post specifically criticizing "database-driven thinking"

Of course, the original post is true only after you view the original post.

 

This article describes:

This article does not discuss or explain the theoretical things. I just want to talk about how to minimize the impact, in conjunction with the CYQ. Data framework.

No matter what the reason is, or whether it is true or not, a database first and then an entity method has been accepted by most people and related development has been carried out in this way.

 

How the CYQ. Data framework responds to changes:Is "how to minimize the impact"

 

Solution 1: enumeration and entity class Introduction

In essence, the CYQ. Data framework adopts a weak index. Therefore, enumeration and entity may not exist.

However, in order to facilitate development, enumeration and entity can be introduced. For all articles related to this framework, enumeration is introduced. Therefore, enumeration is not described much.

 

 

The following describes howIntroduce entity classes that can respond to changes:

For example, the Users table:

Public class Users
{
Public static int ID = 0;
Public static string UserName = "UserName ";
Public static int Password = 2;
Public const int CreateTime = 3;
}

Note:

From this point, we can see that the introduced entities and common attributes are different. Here static attributes can be used, constants, integers, or strings.

Then how should we deal with it??

If you change the UserName of the table Users to MyName, you can change the code line. Other Call methods remain unchanged:

Public static string UserName = "MyName ";

Some people have doubts: What if I change CreateTime to LoginTime? What is your definition above as an integer? Then you can replace it:

Public const string CreateTime = "LoginTime ";

Note:

For this modification, you do not need to modify the configuration in xml or the content of other modules. You only need to modify the words in the Model.

If the field is added, you can add a static member attribute.

 

 

 

Solution 2: Use AutoSetPre to handle the code added and updated on the Interface

This framework provides N methods for adding and updating an attribute. Here, we will give an example of how to add and update an attribute.

 

If it is a normal method, we will assign values to each attribute before updating it, for example:

MAction action = new MAction (TableNames. Users );
Action. Set (Users. UserName, "passing by autumn ");
Action. Update (2 );
Action. Close ();

If we try to use the AutoSetPre method, convert the changes to the front-end UI. For fields with many fields, you can also omit a lot of code such:

MAction action = new MAction (TableNames. Users );
Action. SetAutoPrefix ("txt ");
Action. Update (2, true );
Action. Close ();

Note:

In this way, as long as the foreground UI has a TextBox and its id is txtUserName.

If the UserName of the database is changed to MyName, you only need to modify the control name of the front-end UI. At least you do not need to re-compile the ghost code to modify the UI.

 

To add data, you only need:

MAction action = new MAction (TableNames. Users );
Action. SetAutoPrefix ("txt", "ddl ");
Action. Insert (true );
Action. Close ();

The rest is handed over to the UI for processing.

 

Solution 3: View and custom multi-Table SQL query

View: MAction supports view operations, which are exactly the same as normal table operations. For view changes, you only need to modify the database fields and the view will automatically update for you, so you do not need to handle them at all.

Custom multi-Table SQL: you only need to manage the custom multi-Table SQL in a unified manner, or use the select * method when the performance requirements are not high to avoid the emergence of field names or, because of the unified management, you can easily modify and edit the token update separately. Of course, if you save or map it to xml, you can directly modify the xml, this is also one of the response methods.

 

Solution 4: interface binding

If <% # Eval ("field name") %> is used for binding on your interface, after modifying the database field, you only need to modify the UI, it is not used for encoding.

In another way, if you use the automatic column generation method of the GridView, you can even save the UI.

 

Conclusion:

This framework is highly adaptable to this database change mode. For specific implementation methods, you can directly study the source code.

If you have other questions, leave a message.