Adhesive framework series-Use of the ADO. Net EF data access module

The data access layer of the adhesive framework is based on the ADO. NET Entity Framework, so its usage is basically the same as that of the Entity Framework. To meet the needs of actual projects, we have made some extensions Based on the Entity Framework, mainly including the following:

1. Encrypt Sensitive password fields in database connection strings;

2. The database connection string configuration is separated from the local configuration file (Web. config or app. config) and is centrally configured and managed in the configuration service background;

3. Automatic Data review. As long as the object implements the iauditable interface, the createdon and modifiedon fields are automatically set to the current date when the object is added or modified;

4. Logical deletion, such as some important business data, generally does not allow physical deletion. As long as the object implements the isoftdeletable interface, the data will not be deleted when the delete operation is executed, the value of the isdeleted field is true;

5. The ID is automatically generated. Each object should have an ID field that uniquely identifies itself. If the ID field has no practical significance, You can automatically generate it. When the object implements the iidentifiable interface and does not assign values to the ID field, the system automatically generates a 32-bit continuous guid as the ID;

6. Optimistic Concurrency Control. The entity framework already has the optimistic concurrency control function. The most efficient way is to use the timestamp method. However, this method provides better support for ms SQL Server, it is not suitable for other types of databases. The framework implements Optimistic Concurrency Control Based on the row version. This function is automatically enabled as long as the entity object implements the iversionable interface.

Next let's take a look at how to use it:

(1) define entities

 Public   Class Customer: entity, iauditable, iversionable, isoftdeletable {[stringlength (256)] Public   String Firstname {Get; Set ;}[ stringlength (256)] Public   String Lastname {Get; set;} [stringlength (256)] Public   String Fullname {get { Return   String . Format ( "{0}, {1 }" , This . Lastname, This . Firstname) ;}set {}} [stringlength (256)] Public   String Telephone {Get; set;} [stringlength (256)] Public   String Company {Get; set ;} Public   Decimal Creditlimit {Get; set ;} Public   String Createdby {Get; set ;} Public Datetime createdon {Get; set ;} Public   String Modifiedby {Get; set ;} Public Datetime? Modifiedon {Get; set;} [concurrencycheck] Public   Long Rowversion {Get; set ;} Public   Bool Isdeleted {Get; set ;}}

The User-Defined Object must inherit the abstract class entity. The entity defines the ID of the Identity field and implements some basic methods for object comparison.

 

(2) define dbcontext

 
[Contextattribute ("Customerdbcontext")]ClassCustomerdbcontext: storagecontext {PublicCustomerdbcontext (StringContextname ):Base(Contextname ){}PublicDbset <customer> MERs {Get; Set ;}}
 

The custom dbcontext must inherit the abstract class storagecontext, which encapsulates dbcontext. The storagecontext contextname parameter is called the database context name. Each database context corresponds to an actual database. The database context name can be set in two ways. The first method is to specify the context name through the contextattribute of contextattribute, and the second method is to customize the name of the dbcontext type, for example, if the name of the custom dbcontext type is customerdbcontext, the database context name corresponding to the custom dbcontext type is customerdbcontext. The preceding two methods have the highest priority. If the specified database context is not configured, the default database context defaultcontext is used.

(3) database context Configuration

The database context consists of the database context name, data provider name, and database connection string name. The database context is in the configuration service background

Global configuration> storageconfig> storagecontexts, for example:

 

The system has a default storage context defaultcontext, such:

 

The three components of the database context are as follows:

You can modify the preceding three parts as required.

 

If you want to store the customer information in another database, you need to add the relevant database context configuration. Next we will create a database context configuration named mermerdbcontext for the custom dbcontext above (navigate to the storagecontexts node and click the Add button) as follows:

 

Click OK, for example:

 

When a customerdbcontext node is added, all three subnodes under the defaultcontext node are copied. Modify the nodes as needed. The name of the storage context, that is, the value of the Name node, must be consistent with the name entered when the database context was just created. Both are mermerdbcontext. Because we use the SQL Server databaseProgramThe name is system. Data. sqlclient. To store the customer in the customerdb database separately from other data, change the database name in the database connection string to customerdb. For the final customerdbcontext configuration, see:

 

(4) Data Operations

 adhesiveframework. start (); idbcontextfactory dbcontextfactory = localservicelocator. getservice 
  
    (); 
    using  (customerdbcontext context = dbcontextfactory. createcontext 
   
     () {customer C = 
     New  customer (); C. firstname = 
     "James" ; C. lastname = 
     "Chan" ; context. MERs. add (c); context. savechanges ();} adhesiveframework. end (); 
   
  

AboveCodeAfter successful execution, the customerdb and customer tables of the database are automatically created.

Added data: