The Winform development framework is compatible with multiple database types at the same time.

The Winform development framework is compatible with multiple database types at the same time.

In many application systems, although a database is generally used for running, the business system may be deployed on different types of databases due to various situations, if the developed system can easily support switching between multiple databases, it can reduce a lot of troubles and improve the adaptability and robustness of the system. In another case, due to the constant expansion of the business database or the convenience of database cutting and isolation, different business databases are sometimes split, such as the database providing permissions and the customer relationship management database, workflow databases, Enterprise Operation databases, and so on. Therefore, two or more databases are used in one system.

In my earlier article "Winform Development Framework supports switching multiple database types and splitting databases, this section describes how the framework supports sharding of multiple databases in a project. In general, we split multiple databases in a single database type, but there are also abnormal requirements, for example, we may store some conventional databases in the local SQLite database, and some other data in other types of databases on the LAN (such as SQLServer). This type of Database supports multiple types at the same time, when creating BLL-layer classes for users, can the database be dynamically specified?

Of course you can. Just adjust the creation method slightly based on the above.

1. Support for coexistence of various types of database processing

As mentioned earlier, to split a database, we need to add a SetConfigName method in the Data Access Base Class AbstractBaseDAL to specify a specific database configuration project, as shown below.

/// <Summary> // super base class of the data access layer. The data access base classes of all databases are inherited from this super base class, including Oracle, SqlServer, Sqlite, MySql, Access, etc. // </summary> public abstract class implements actbasedal <T> where T: BaseEntity, new () {// <summary> /// set the database configuration item name /// </summary> /// <param name = "dbConfigName"> database configuration item name </param> public virtual void SetDbConfigName (string dbConfigName) {this. dbConfigName = dbConfigName ;}....................}

So this time, we only need to adjust it on this basis to achieve the transformation of different databases at the same time. Because in the framework, generally, we have implemented multiple database access logics (as shown below). Therefore, it is certainly okay to switch over (ensure that there is a database ).

The method is to add a public method in The BLL layer to set configuration items and database types, as shown below.

/// <Summary> /// reinitialize the data access layer based on the parameter information (for example, you can specify different data access layers) /// </summary> /// <param name = "dbConfigName"> database configuration item name </param> /// <param name = "componentDbType"> database type, by default, it is read from ComponentDbType. If dbConfigName specifies different types of database connections, you must specify componentDbType. </Param> public void SetConfigName (string dbConfigName, string componentDbType = null) {// when componentDbType = null, the value of ComponentDbType from the configuration item string dbType = componentDbType; if (string. isNullOrEmpty (componentDbType) {AppConfig config = new AppConfig (); dbType = config. appConfigGet ("ComponentDbType");} string DALPrefix = GetDALPrefix (dbType); this. dalName = bllFullName. replace (bllPrefix, DALPrefix ); // Replace the intermediate BLL. is DAL ., is the full name of the DAL class baseDal = Reflect <IBaseDAL <T>. create (this. dalName, dalAssemblyName); // construct the object class if (! String. IsNullOrEmpty (dbConfigName) {baseDal. SetDbConfigName (dbConfigName); // set the database configuration item name }}

In this way, in addition to setting the EnterpriseLibrary configuration item, you can also specify the type of the database. You do not need to use the unified ComponentDbType value.

After the following code is processed, we can switch the BLL layer object to another type of Database (SQLite) when accessing other databases, regardless of how other classes change, this Province Data Accesses the data in the SQLite database.

BLLFactory<Province>.Instance.SetConfig("sqlite", "sqlite");

2. Support for multi-database operations of the basic class CommonDAL to achieve access to different databases

Sometimes, in a relatively small application, we want to flexibly perform some simple operations on the database table and do not want to use the code generation tool to generate the code of the entire architecture. At this time, this CommonDAL comes in handy. The table that can be quickly accessed to the database is defined as follows.

The following constructor is used for this class. The parameters are table names, primary key fields, and database types.

/// <Summary> /// default constructor /// </summary> public CommonDAL () {}/// <summary> /// specify the table name and primary key, construct the base class /// </summary> /// <param name = "tableName"> table name </param> /// <param name = "primaryKey"> table Primary Key </param> /// <param name = "dbType"> database type, if it is null, obtain the ComponentDbType key value from the configuration file </param> public CommonDAL (string tableName): this (tableName, null, null) {}/// <summary> /// specify the table name and primary key, construct the base class /// </summary> /// <param name = "tableName"> table name </param> /// <param name = "primaryKey"> table Primary Key </param> /// <param name = "dbType"> database type, if it is null, obtain the ComponentDbType key value from the configuration file </param> public CommonDAL (string tableName, string primaryKey, string dbType = null): this (){}

 

This is a simplified version of the AbstractBaseDAL base class that provides most of the database operation methods we can use.

For example, in an example program that verifies the view and its format, I used this class to implement fast database operation processing.

/// <Summary> /// task used to determine whether the view name exists /// </summary> public class ViewNameExistJob: IExecuteJob {public bool Execute () {List <string> list = DataHelper. getViewList (); bool allSuccess = true; foreach (string view in list) {CommonDb dal = new CommonDb (view, "F_Guid"); try {DataTable dt = dal. getReaderSchema (view);} catch (Exception ex) {allSuccess = false; LogTextHelper. error (string. format ("View: {0} does not exist . {1} ", view, ex. Message) ;}} if (allSuccess) {LogTextHelper. Info (" view all exist. ") ;}Return allSuccess ;}}

Or other databases.

CommonDb dal = new CommonDb (view, "F_Guid"); try {int count = dal. getRecordCount (); if (count = 0) {LogTextHelper. info (string. format ("view [{0}] data is empty. Please check it! ", View); allSuccess = false ;}} catch (Exception ex) {allSuccess = false; LogTextHelper. Error (string. Format (" view: [{0}] does not exist. {1} ", view, ex. Message ));}

In this way, you can switch between multiple databases at will, but this is used for simple database access. for processing classes that require a variety of business encapsulation, we still use the conventional layered framework mode to process data.