Schema mode: Data Source mode: Table Data gateway, row data gateway, and active record)

I. Table Data Gateway)

The table data entry provides all the SQL statements used to access a single table or view (including join table queries). Generally, a table is a class. Other code uses it to achieve database interaction. Based on this feature, the table data entry is well integrated with the transaction script code and the table module.

During query, the table data interface can return the dataset, DTO, or DTO list. The form of DTO and DTO is described in the transaction script code. However, a problem arising from the use of DTO is that DTO is derived everywhere. For how to reduce the number of DTO derived everywhere, see "here".

In traditional practices, the table data entry and domain model are not used together. The domain model is used, and the data er is generally used.

The table data entry code is everywhere, for example:

Public class userdal: sqlserverdal <user>
{
Public override ilist <user> getlist ()
{
String SQL = "select * from [el_organization]. [user] Where State = 1 ";
VaR DS = sqlhelper. executedataset (commandtype. Text, SQL );

Ilist <user> oblist = new list <user> ();
Foreach (datarow row in DS. Tables [0]. Rows)
{
Oblist. Add (new user {id = (string) Row ["ID"], name = (string) Row ["name"]});
}

Return oblist;
}

Public override user findone (User t) {return NULL ;}

Public override void insert (user model ){}

Public override void Update (User t ){}

Public override void Delete (User t ){}
}

Public class user
{
Public String ID;
Public string name;
}

 

2. Row data Gateway)

The row data entry, a row record in the table has an object.

Public class userdal
{
Public String ID;
Public string name;

Public void load (Dataset DS)
{
// Get the id based on DS, which may be obtained from userfinderdal.
}

Public void insert ()
{
String SQL = @ "insert into [el_organization]. [user] ('id', 'name') values ("+ this. ID + "," + this. name + ")";
VaR DS = sqlhelper. Execute (commandtype. Text, SQL );
}

Public void Update ()
{
// Update this;
}

Public void Delete ()
{
// Delete this;
}
}

Public class userfinderdal
{
Public userdal findone (string ID)
{
String SQL = "select * from [el_organization]. [user] Where id =" + ID;
VaR DS = sqlhelper. executedataset (commandtype. Text, SQL );

Foreach (datarow row in DS. Tables [0]. Rows)
{
Return new userdal {id = (string) Row ["ID"], name = (string) Row ["name"]};
}

Return NULL;
}

Public list <userdal> findlist (string name)
{
Return NULL;
}

}

As you can see, compared with the table database portal, You can query the data in the database. The table database portal only needs one class, while the row data portal requires two classes, itself is also used as a database entity, but is responsible for its own update insert Delete. to query itself, set, or operation set, another class is required.

 

Ii. Active record)

Activity records are similar to row data entries. The difference between the two is that the row data entry only has database access, and the activity records have both database access and domain logic. In the row data entry, we generally use two classes, but in the activity record, there is generally no such restriction. Generally, a class may appear more refreshing.

A domain model is generally used in collaboration with activity records or data mappers.

In software development, the primary practice is: Transaction scripts;

The more advanced approach is activity recording. Generally, when it is found that the code of the transaction script is complex enough to be difficult to maintain, You can gradually create activity records and then add behavior to them, that is, wrap the table into activity records, then add the domain logic.

The most complex and advanced approach is the domain model.

From the above description, we can easily know how to modify the code of the table data entry or row data entry in this article, and then make it an activity record.

Public class useractiverecord
{
Public String ID;
Public string name;

Public void load (Dataset DS)
{
// Get the id based on DS, which may be obtained from userfinderdal.
}

Public void insert ()
{
String SQL = @ "insert into [el_organization]. [user] ('id', 'name') values ("+ this. ID + "," + this. name + ")";
VaR DS = sqlhelper. Execute (commandtype. Text, SQL );
}

Public void Update ()
{
// Update this;
}

Public void Delete ()
{
// Delete this;
}

Public useractiverecord findone (string ID)
{
String SQL = "select * from [el_organization]. [user] Where id =" + ID;
VaR DS = sqlhelper. executedataset (commandtype. Text, SQL );

Foreach (datarow row in DS. Tables [0]. Rows)
{
Return new useractiverecord {id = (string) Row ["ID"], name = (string) Row ["name"]};
}

Return NULL;
}

Public list <useractiverecord> findlist (string name)
{
Return NULL;
}

Public void someotherlogic ()
{
}
}

From the code above, the activity record mode is not in the business logic layer and data access layer, because they are integrated. The transaction script, table data entry, and row data entry can have more or less two layers of concepts.

Schema mode: Data Source mode: Table Data gateway, row data gateway, and active record)