How to build your own data access Layer 3

In the previous article, how to build our own data access layer 2, we have implemented the corresponding features of the data access layer. Now we have finished the work. Let's take a look at the code section and try the features of the previous article:

 
 

  
  
String sqlText = "select id, NAME, val from test ";
  
  
String columns = "ID, NAME, VAL ";
  
  
DataSet ds = new DataSet ();
  
  
DataExecutor execObj = new MSSqlExecutor ();
  
  
DataMapping map = new DataMapping ();
  
  
Map. ExecuteObject = execObj;
  
  
Map. TableName = "TEST ";
  
  
Map. KeyColumns = "ID ";
  
  
Map. Columns = "ID, NAME, VAL ";
  
  
DataMapping map = new DataMapping (execObj. GetInstant (), "TEST", "ID", columns );
  
  
Map. Fill (sqlText, "TEST ");
  
  
Map. SetCommands (DataCommandType. Insert | DataCommandType. Update | DataCommandType. Delete, ds );
  
  
// Add, delete, and modify data in DataTable Mode
  
  
Bool isSuccess = execObj. Update ();
 
 

I have completed the read and write operations on the database. At least I don't need to write a large segment of parameter passing code. All the functions have been implemented. Is that all done?

Take a closer look at the above Code. In fact, there are still problems that have not been solved. Let's look at this sentence:

 
 

  
  
DataExecutor execObj = new MSSqlExecutor(); 
 
 

The execution object of MSSql is instantiated directly in the Code, so that the switching problem between databases proposed at the beginning is not fundamentally solved.

Let's look at the previous article. There is a method of public IDbConnection GetConn (), which is used to obtain the data connection object. It didn't explain how to implement it before.

We know that DBConnection has two key information:

1. What kind of database is connected to? This is already solved.

2. Pass the account information connected to the database and the ConnectionString of the database access information, which is not mentioned.

Let's see how it was previously done at the second point:

 
 

  
  
Public IDbConnection GetConn ()
  
  
{
  
  
If (conn! = Null)
  
  
{
  
  
Return conn;
  
  
}
  
  
Conn = new SqlConnection ();
  
  
Conn. ConnectionString = connection string;
  
  
Return conn;
  
  
}
 
 

Where does the connection string come from?

In summary, to complete the final data access output, two problems need to be solved:

1. dynamically switch between different databases.

2. Solve the Problem of data connection string source.

Next we will solve these two problems. First we will solve the second problem. There is a simple method to write the connection string into the configuration file, the data access layer only needs to know the KEY value it passes:

 
 

  
  
<appSettings>  
  
  
    <add key="ConnStr" value="server=.;uid=sa;password=123456;database=DATA_BASE;max pool size=300"/>  
  
  
</appSettings> 
 
 

The first problem is solved, and only the last one is left. How can we dynamically switch different databases? That is to say, we don't need to create a NEW object when using it, instead, we create an object through a third party. In fact, we have proposed a solution in the design mode. If you are interested, you can study it on your own. Here we only need to use the simple factory mode:

 
 

  
  
public sealed class ExecutorFactory  
  
  
{  
  
  
    public static DataExecutor Create()  
  
  
    {  
  
  
        return Create(DatabaseType.MSSql);  
  
  
    }  
  
  
    public static DataExecutor Create(DatabaseType dbType)  
  
  
    {  
  
  
        AbstractDataBase dataBase = null;  
  
  
        Switch(dbType)  
  
  
        {  
  
  
            case DatabaseType.MSSql:  
  
  
                dataBase = new MSSqlDataBase();  
  
  
                break;  
  
  
            case DatabaseType.Oracle:  
  
  
                dataBase = new OracleDataBase();  
  
  
                break;  
  
  
        }  
  
  
        return dataBase.Create();  
  
  
    }  
  
  
} 
 
 

Now you can replace this code: DataExecutor execObj = new MSSqlExecutor ();

Replace with: DataExecutor execObj = ExecutorFactory. Create ();

At this point, the problem has been solved. to switch to a database, you only need to change DatabaseType to the corresponding database type.

Next, let's take another consideration. If the database type does not need to be changed, can it be implemented?

The configuration file is used, but not the type string provided at this time, but the actual information of the Data executor assembly, which can be achieved by using. NET's natural advantage reflection.
The final configuration file is:

 
 

  
  
<appSettings>  
  
  
    <add key="ConnStr" value="server=.;uid=sa;password=123456;database=DATA_BASE;max pool size=300"/>  
  
  
    <add key="DBExecutor" value="FM.DataAccess, FM.DataAccess.MappingExcuter.MSSqlExecutor"></add>  
  
  
  </appSettings> 
 
 

Transformed Factory:

 
 

  
  
public sealed class ExecutorFactory  
  
  
    {  
  
  
        public static DataExecutor Create()  
  
  
        {  
  
  
            return Create(null);  
  
  
        }  
  
  
        public static DataExecutor Create(string dataBaseTypeKey)  
  
  
        {  
  
  
            return Create(dataBaseTypeKey, null);  
  
  
        }  
  
  
        public static DataExecutor Create(string dataBaseTypeKey, string connStrKey)  
  
  
        {  
  
  
            if (string.IsNullOrEmpty(dataBaseTypeKey))  
  
  
            {  
  
  
                dataBaseTypeKey = "DBExecutor";  
  
  
            }  
  
  
            string[] sltDataBaseType = ConfigReader.Read(dataBaseTypeKey).Split(',');  
  
  
            string asselblyName = sltDataBaseType[0];  
  
  
            string nameSpace = sltDataBaseType[1].Trim();  
  
  
            Assembly assembly = Assembly.Load(asselblyName);  
  
  
            DataExecutor execObj = assembly.CreateInstance(nameSpace) as DataExecutor;  
  
  
            execObj.SetConnectionString(connStrKey);  
  
  
            return execObj;  
  
  
        }  
  
  
    } 
 
 

So far, the data access layer has finally been completed. Of course, there are still many problems to solve here, but its basic framework has been formed. Based on this, we can achieve our own expansion based on business changes, only by constantly updating can we form a complete data access layer.