Simplifies database-based dotnet application development

Analysis

To do a database based application, we have a lot of duplication of work to do, build tables, write and add and delete SQL statements, write and database table corresponding entity classes, write execution SQL C # code, write add, modify, List, Detail page and so on. All of these activities revolve around a data table, there are many or mapping in the. NET domain, but a lot of solutions are useful, but the principles are complex and performance is difficult to grasp, so we can do a lightweight ORM solution. With an ORM framework that writes C # entity classes from a datasheet, you can actually write a code generator to help us build, and even the code generator can help us generate some interface code. We probably need to solve the following problems

1, we should have a common database operation Help class, similar to Microsoft's Daab, but it is best to support a variety of databases;

2, we want to have a simple ORM framework, can easily use C # code for database access operations, but also to maximize performance, such as the use of parameterized query;

3, we want to have a code generator to help us solve some repetitive labor, such as the generation of entity classes, generate calls to the stored procedure C # code, etc.;

Around these 3 questions, we Yi Yilai unfold

One, common database eat Operation Help class

Ado.net 2.0 provides a set of database-independent models for our access to the database, and its core class is DbProviderFactory, which follows the provider pattern of abstracting a provider from the operations of various databases, Then by a variety of databases to write with the specific database-related provider, and then configure the runtime to facilitate the switching of the database, and as little as possible without modifying the business logic layer of code, business logic layer relies on the abstract provider. This is also a typical dependency inversion, which means that the business logic says what interfaces I need, I rely on those interfaces, and let others implement these interfaces, and then load the specific classes that implement those interfaces at run time.

To improve performance, reduce SQL Server execution plan recompilation, we try to use parameterized queries, and a fixed statement or stored procedure its ado.net parameters are fixed, so we can cache these parameters to avoid each execution of SQL statements to innovate new parameter objects. In addition, the parameters of OLE DB's Ado.net provider are not named, so assign values to the parameters in order.

For ease of use, we provide the following APIs for executing SQL statements

Public System.Data.DataSet Sqlexecutedateset (String sql, string[] 

paramters, params object[] values)

public System.Data.DataTable sqlexecutedatetable (String sql, string[] 

paramters, params object[] values) public

int Sqlexecutenonquery (String sql, string[] paramters, params 

object[] values)

public System.Data.Common.DbDataReader sqlexecutereader (String sql, 

string[] paramters, params object[] values)

public Object Sqlexecutescalar (String sql, string[] paramters, params 

object[] values)