在很多應用系統里面，雖然一般采用一種數據庫運行，但是由於各種情況的需要，可能業務系統會部署在不同類型的數據庫上，如果開發的系統能夠很方便支持多種數據庫的切換，那可以為我們減少很多煩惱，同時提高系統的適應性和強壯型。還有一種情況，由於業務數據庫的不斷膨脹或者方便數據庫的切割隔離，有時候也會把不同的業務數據庫進行分拆，如權限提供數據庫，客戶關系管理數據庫，工作流程數據庫，企業營運數據庫等等，因此在一個系統里面，同時使用2個或者以上的數據庫的情況也是有的。針對這兩種情況，本文介紹在我的Winform開發框架（也使用我的其他框架），如何具體處理這兩個問題的。
在我的各種開發框架里面，底層都是采用同一種數據庫的訪問方式，就是采用了Enterprise Library的數據庫訪問模塊，這個是微軟開源的企業應用模塊，里面各種應用模塊，都堪稱是開發的最佳實踐。當然利用里面的數據庫訪問模塊，是很廣泛的，這個數據庫訪問模塊，可以通過配置的方式支持多種數據庫的變化。因此整合到我的Winform開發框架里面，也很容易實現這種多數據庫的方式處理。
Winform開發框架，常見的分層模式，可以分為UI層、BLL層、DAL層、IDAL層、Entity層、公用類庫層等等，B/S的Web開發框架也是提供類似的架構模式，它們只是Web界面層有所不同，這樣就給我們提供了一個統一性的開發模式，使得開發起來更加高效，統一性更好。框架界面層以下的架構設計圖如下所示。
1、支持多數據庫的設置
1）數據庫訪問基類的了解
為了介紹支持多種數據庫的模式，我們需要先來了解下整個框架的層次結構。
AbstractBaseDAL是抽象了所有數據庫實現的超級基類。
BaseDALSQL是針對SqlServer數據庫部分調整基類（很小的調整）。
BaseDALSQLite是針對Sqlite數據庫的部分調整基類（很小的調整）。
BaseDALMySql是針對MySqlite數據庫的部分調整基類（很小的調整）。
BaseDALAccess是針對Access數據庫的部分調整基類（很小的調整）。
IBaseDAL是所有基礎數據庫訪問類的接口。
數據訪問接口實現層（如Customer）和接口定義層（ICustomer）一樣，都有一個基類，如基於SqlServer實現的基類為BaseDALSQL，這個基於SqlServer的數據訪問基類，它也是繼承自一個超級基類（大多數的實現在這里）AbstractBaseDAL。他們之間的繼承關系如下所示
而我們剛才在項目工程的圖里面看到，BaseDALSQL、IBaseDAL、AbstractBaseDAL這些類庫由於具有很大的通用性，為了減少在不同的項目中進行復制導致維護問題，因此我們全部把這些經常使用到的基類或者接口，抽取到一個獨立的類庫里面，為了和普通的DotNET公用類庫命名進行區分（WHC.Framework.Commons），我們把它命名為WHC.Framework.ControlUtil。
2）多數據庫的代碼實現
為了實現多數據庫的支持，我們需要在配置文件里面讀取相關的配置，看具體是構造那種該數據庫的，然后進行初始化不同的程序集類，從而實現調用不同數據庫類型的數據庫訪問類。
在BaseBLL的Init函數里面的實現代碼如下所示。
#region 根據不同的數據庫類型，構造相應的DAL層 AppConfig config = new AppConfig(); string dbType = config.AppConfigGet("ComponentDbType"); if (string.IsNullOrEmpty(dbType)) { dbType = "sqlserver"; } dbType = dbType.ToLower(); string DALPrefix = ""; if (dbType == "sqlserver") { DALPrefix = "DALSQL."; } else if (dbType == "access") { DALPrefix = "DALAccess."; } else if (dbType == "oracle") { DALPrefix = "DALOracle."; } else if (dbType == "sqlite") { DALPrefix = "DALSQLite."; } else if (dbType == "mysql") { DALPrefix = "DALMySql."; } #endregion this.dalName = bllFullName.Replace(bllPrefix, DALPrefix);//替換中級的BLL.為DAL.，就是DAL類的全名 baseDal = Reflect<IBaseDAL<T>>.Create(this.dalName, dalAssemblyName);//構造對應的DAL數據訪問層的對象類
在具體的業務對象的調用的時候，我們不知道它具體是調用哪個數據庫的處理類進行處理的，只需要調用它的基礎接口就可以了，如下是界面層的部分調用代碼。
//刪除關聯的附件 if (!string.IsNullOrEmpty(ids)) { string[] idArray = ids.Split(','); foreach (string id in idArray) { InformationInfo info = BLLFactory<Information>.FindByID(id); if (info != null && !string.IsNullOrEmpty(info.Attachment_GUID)) { BLLFactory<FileUpload>.Instance.DeleteByAttachGUID(info.Attachment_GUID); } } }
在具體的配置文件里面，我們就可以根據需要配置好相關的數據庫了。
根據Enterprise Library的配置，我們只要制定了<dataConfiguration defaultDatabase="sqlserver">，那么就會獲取sqlServer的節點，而代碼通過解析ComponentDbType配置項，就可以構造對應的數據庫訪問對象了。兩者合一就可以正確獲取到處理對象，並成功處理數據庫的訪問。
<configuration> <configSections> <section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data"/> </configSections> <connectionStrings> <add name="sqlserver" providerName="System.Data.SqlClient" connectionString="Persist Security Info=False;Data Source=(local);Initial Catalog=MVCWebMis;Integrated Security=SSPI"/> <add name="access" providerName="System.Data.OleDb" connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=|DataDirectory|\ComponentData.mdb;User ID=Admin;Jet OLEDB:Database Password=;"/> <add name="sqlite" providerName="System.Data.SQLite" connectionString="Data Source=|DataDirectory|\ComponentData.db;Version=3;"/> <add name="oracle" providerName="System.Data.OracleClient" connectionString="Data Source=whcdb;User ID=whc;Password=whc"/> </connectionStrings> <dataConfiguration defaultDatabase="sqlserver"> <providerMappings> <add databaseType="EntLibContrib.Data.SQLite.SQLiteDatabase, EntLibContrib.Data.SqLite" name="System.Data.SQLite"/> </providerMappings> </dataConfiguration> <appSettings> <!--組件的數據庫類型：access、sqlserver、sqlite等--> <add key="ComponentDbType" value="sqlserver"/>
2、支持分拆不同數據庫的設置
上面介紹的方式，一次性只能訪問一個數據庫，因此默認在代碼構造數據庫訪問對象的時候，是通過下面的代碼進行的。
Database db = DatabaseFactory.CreateDatabase();
這樣每次只會獲取defaultDatabase設置的數據庫進行構造，如果我們在一個系統里面，同時支持多個數據庫的訪問，那么我們應該如何處理呢。
在框架的基類AbstractBaseDAL里面，我們對構造數據庫的代碼進行了封裝。
/// <summary> /// 根據配置數據庫配置名稱生成Database對象 /// </summary> /// <returns></returns> protected virtual Database CreateDatabase() { Database db = null; if (string.IsNullOrEmpty(dbConfigName)) { db = DatabaseFactory.CreateDatabase(); } else { db = DatabaseFactory.CreateDatabase(dbConfigName); } return db; }
而每個DAL層都會繼承自AbstractBaseDAL，這樣也就可以通過在DAL層指定dbConfigName進行使用不同的數據庫的了。
但是這樣問題出現了，假如我們有5個不同類型（SqlServer、Oracle、Mysql、Access、Sqlite)的數據庫的DAL層，那么每個DAL層的實現類都要寫一些代碼，這樣挺不方便，那么是否可以把它抽象到BLL層，這樣只寫一次配置就可以了，這個思路很好，我們具體來看看如何實現。
1）在IBaseDAL層定義接口
/// <summary> /// 數據訪問層的接口 /// </summary> public interface IBaseDAL<T> where T : BaseEntity { /// <summary> /// 設置數據庫配置項名稱 /// </summary> /// <param name="dbConfigName">數據庫配置項名稱</param> void SetDbConfigName(string dbConfigName);
............. }
2、在AbstractBaseDAL添加默認實現代碼
/// <summary> /// 數據訪問層的超級基類，所有數據庫的數據訪問基類都繼承自這個超級基類，包括Oracle、SqlServer、Sqlite、MySql、Access等 /// </summary> public abstract class AbstractBaseDAL<T> where T : BaseEntity, new() { /// <summary> /// 設置數據庫配置項名稱 /// </summary> /// <param name="dbConfigName">數據庫配置項名稱</param> public virtual void SetDbConfigName(string dbConfigName) { this.dbConfigName = dbConfigName; }
.................... }
3、在BaseBLL里面的Init函數進行調用設置處理
/// <summary> /// 參數賦值后，初始化相關對象 /// </summary> /// <param name="bllFullName">BLL業務類的全名（子類必須實現）,子類構造函數傳入this.GetType().FullName</param> /// <param name="dalAssemblyName">數據訪問層程序集的清單文件的文件名，不包括其擴展名。設置為NULL或默認為Assembly.GetExecutingAssembly().GetName().Name</param> /// <param name="bllPrefix">BLL命名空間的前綴（BLL.)</param> /// <param name="dbConfigName">數據庫配置項名稱</param> protected void Init(string bllFullName, string dalAssemblyName = null, string bllPrefix = "BLL.") { ............. baseDal.SetDbConfigName(dbConfigName); //設置數據庫配置項名稱 }
4、在具體BLL層的業務類進行初始化處理。
/// <summary> /// 政策法規公告動態 /// </summary> public class Information : BaseBLL<InformationInfo> { public Information() : base() { base.Init(this.GetType().FullName, System.Reflection.Assembly.GetExecutingAssembly().GetName().Name, "BLL.", "annotherConfig" ); }
這樣設置后，我們具體調用的代碼不變，但是指定業務的數據庫訪問已經使用了特定的配置項名稱了，如果配置項不存在，那么還是會獲取默認的配置項進行處理了。
通過這樣的實現步驟，我們就能實現在一個業務系統里面，分拆不同的數據庫，進行統一管理，而且又不會增加額外的調用難度，對於我們很多業務表，這種框架的處理方式 ，應該是不錯的。