How C # makes the data access process more transparent

Access | process | data | transparent

In writing database operation methods, we often consider the method of internal processing of connection, transaction, etc., mainly convenient for the subsequent integration of different methods of expansion. But most of the time write database operation method is closed, open connection or transaction processing inside the method, this is to meet the need of the existing requirement, save the trouble of invoking the method (because the information that must be defined in the calling method is passed in). While this satisfies the existing requirements, the problem arises when the function extension needs to integrate several methods, because the method is closed when you need multiple methods to use a connection or transaction at the same time, you must modify the original method , although it is possible to overload a new version of a method to suit the needs of the novel, the modification and refactoring of the code is not an easy task.

Briefly describe the problem:

public void A ()
{
........
}

public void B ()
{
.......
}

The above two methods are not a problem to use alone, as they are all independent. What happens when the following conditions are present?

public void C ()
{
A ();
b ();
....
}

When executing this method, it is possible to ensure that database access in a and B must use the same connection, and that the data operations of the two methods must use the same transaction if the data is to be fully rounded. Since the beginning of writing A and B methods does not take into account these circumstances, all we can do at this time is to refactor the A and B methods to meet the original and present needs.

If we do not modify a and B to meet the needs of C that is a good thing, so that developers have more time to deal with business-related problems. Sometimes think about it. Dotnet provides a DataContext (database operation context object) How nice it is to write the database operation code without concern for what to use connection and transaction, as determined by the current DataContext. Although I have this idea to achieve, but dotnet can provide is the best thing.

public void C ()
{
using (DataContext context = new DataContext ())
{
A ();
b ();
....
}
}
public void D ()
{
using (DataContext context = new DataContext ())
{
C ();
....
}
}

Add:

In fact, in my mind datacontext not necessarily to be explicitly created, you can configure a default DataContext in a program programmatically. The functionality of the following code is not fully implemented.

Table orders = new Table ("Orders");
Table OrderDetails = new Table ("[Order Details]");
OrderDetails. Delete (Orderdetails._orderid = = 10500);
Orders. Delete (Orders._orderid = = 10500);

The code can run even if you do not have to explicitly create DataContext. To ensure data integrity you can do this:

using (TransactionContext tran = new TransactionContext ())
{
Table orders = new Table ("Orders");
Table OrderDetails = new Table ("[Order Details]");
OrderDetails. Delete (Orderdetails._orderid = = 10500);
Orders. Delete (Orders._orderid = = 10500);
Tran.commit ();
｝

In the process of writing code can put these things aside, need to define the corresponding DataContext.

If a high degree of transparency is required, only one datacontext is far from sufficient and must provide the encapsulation of the corresponding data manipulation.