Data | database
(a). Prologue
1. Most of the actual software development is developed by the team, and often this happens when a programmer only designs the database and is written by another programmer. There is a problem. Design Database programmer Design Database field name custom is somewhat different from writing code programmer database Naming habits. For example, the database programmer named "CustomerName" to the custom name, while the writer code programmer used to name "Cusname" so that the programmer could use a lot of similar: dataset.row[0]["Cusname" when using the code. This will be an error in the update, if a large number of such cases, not only increase the time to modify the development of bugs, but more importantly will make the entire project code pages difficult to unify.
2. You can implement client naming that is not subject to database constraints. For example, the two name fields in the two tables in the database are: CustomerName and projectname; The client is in the relevant interface, the name of the paragraph is not necessary to know which table is the name of the field, directly to write name on it.
This article is to solve the above two point requirements.
(ii). Solutions
1.
In fact, SqlDataAdapter has already implemented this function. It implements column mappings, which correspond to the column programmer custom columns of the database. An example is provided:
With Customer table customers, the following will map the fields below, the specific code is as follows:
SqlDataAdapter myadapter = new Dqldataadapter ();
DataTableMapping mymapping = new DataTableMapping ();
mymapping = MyAdapter.TableMappings.Add ("Customer", "Customer"); Tell the bridge and add the mapping object
MYMAPPING.COLUMNMAPPINGS.ADD ("CustomerID", "id"); The field name in the actual database is: CustomerID, the ID field name can be used when the actual//is being manipulated. For example:
Ds. table["Customer"]. row[0]["id"]; Represents the customer Number column
MYMAPPING.COLUMNMAPPINGS.ADD ("CustomerName", "name");
MYMAPPING.COLUMNMAPPINGS.ADD ("Customeremail", "email");
Myadapter.fill (ds, "Customer");
The above can only be used when using the mapping operation. This section of the name can be customized after the mapping. SqlDataAdapter will make them
correspond to them as the same column.
2. Solve the problem of site unification:
A.
Suppose you have code in 10 pages:
Ds. table["Customer"]. row[0]["CustomerName"];
Now for some reason, to modify a database table field, you need to change the fields in the physical database: CustomerName to: Cusname based on the current situation, and to go to these 10 pages, find all the:
Ds. table["Customer"]. row[0]["CustomerName"];
and change it to: DS. table["Customer"]. row[0]["Cusname"];
Ah, to change a field to bring so much trouble, if more than a number of tables to change the number of fields, the amount of time consumed and maintenance difficult to imagine the degree. Here's how to solve this problem.
B.
Defines a class and inherits the DataSet. The code is as follows:
Public Class Customer:dataset
{
Public Enum Field
{
ID = 0; These columns correspond correctly to the actual field names after obtaining data from the dataset's internal table. Control here Yourself
Name = 1;
Email = 2;
Password = 3;
}
}
OK, the last step, the way to use this:
Ds. table["Customer"]. Row[0][customer.field.id]; Take a column value
Compared to: DS. table["Customer"]. row[0]["CustomerID"];
It's more convenient, isn't it?
This way, if the physical database field is modified, the code is not modified at all (even the class itself does not have to be modified).
Thanks for reading!