三層結構引入原廠模式後的模型

普通的三層結構：UI / BLL / DAL ，資料實體使用 Model 封裝。這種“三層結構”之間是順序的調用關係，UI 調用 BLL ，BLL 將操作組織並安排 DAL 層，DAL 層操作資料庫，每層之間的關係都很緊密，所以協同開發時互相的依賴性較強，項目結構耦合度大。

基於高內聚低耦合的原則，層和層之間的調用考慮引入介面 IDAL 進行規範和分割。BLL 層要求 DAL 層實現的功能先定義好介面 IDAL ，BLL 層就可以借用這些介面去完成商務程序，不必關心實現細節。而 DAL 層只需要按照 IDAL 介面中的定義的操作分別實現，就可以滿足 BLL 的要求。這樣，使用介面對層和層之間的調用實現分離，設計時都互相不需要瞭解細節，而在程式運行時，只需要讓 BLL 層的介面引用指向對應的實際 DAL 對象，程式自然調用實現好的 DAL 中的功能。

程式通過介面實現了更靈活的分層，但畢竟介面引用哪個 DAL 層對象還是要在 BLL 層進行管理。在資料庫表很多，DAL 對象也就會很多的情況下，BLL 層中關於 DAL 的管理也需要很多工作，如何管理更方面？原廠模式。

原廠模式，顧名思義，就是生產某件產品的場所，在程式中起到的也是類似的功能，作用就是生產各式各樣的 DAL 對象。這樣，BLL 層在需要介面的引用指向對應的 DAL 對象的時候，只需要向工廠要就行了，具體是如何產生的那個對象，BLL 不需要關心。這個架構中，DALFactory 工廠起到的作用就是生產各種 DAL 產品，交給 BLL 層使用，如果需要修改某個 DAL 的應用，只需要在工廠中修改，BLL 依舊還是向工廠要對應的產品即可。

範例程式碼：

·BLL 層 :

public class UserService

{ private IUserManager ium = DALFactory.CreateUserManager(); }

·DALFactory 層 :

public class DataAccess

{

public static IUserManager CreateUserManager()

{ return new UserManager(); }

}

·DAL 層 :

public class UserManager{ ...... }

這樣，工廠在程式當中就起到裝配的作用，將 DAL 層的對象裝備到 BLL 層中使用。

以上是簡單工廠的模型，如果考慮程式的資料庫需要在 SQL Server 和 Oracle 之間切換的話，就很有可能需要 SQLDAL 和 OracleDAL 兩套資料訪問層。因為以前已經引入的介面，各種資料庫無非就是不同的實現 IDAL 層的方式而已，對 BLL 層沒有影響。如果切換資料庫的話，工廠中的各個 Create 方法中需要返回的對象，就必須改成不同的 SQL 和 Oracle 對象。

比如：

return new SQLUserManager(); 或者 return new OracleUserManager();

切換資料庫時，工廠中的所有 DAL 對象都需要變成另外一類，數量大的情況下，修改也是相當費力，所以，一般考慮資料庫切換一個或多個的情況下，在設計工廠中 Create 方法時，會使用：

public class DataAccess

{

private static string dbName = "SQL";

public static IUserManager CreateUserManager()

{

if(dbName == "SQL") return new SQLUserManager();

if(dbName == "Oracle") return new OracleUserManager();

}

}

通過一個字串的判斷，確定當前需要的 DAL 物件類型，維護時，只需要修改 dbName 就可以實現切換。

這樣做的好處顯而易見，但問題也同樣存在。如果現在需要另一種 Access 資料庫的切換，肯定需要再加一條：if(dbName == "Access") return new AccessUserManager(); DAL 對象很多，需要加的就很多，還是很麻煩。這時大家可能發現，各種資料庫對應的 UserManager() 的區別就在一個名字上，而且格式很規範，如何根據名字動態產生對應的資料庫 DAL 對象呢？反射！

反射的機制允許程式在編譯時間不知道某些代碼的存在，而在運行時動態訪問記憶體中的代碼，靈活性可想而知。代碼變成：

public class DataAccess

{

private static string path = "UserMIS.SQLDAL";

private static string dbName = "SQL";

public static IUserManager CreateUserManager()

{

return (IUserManager) Assembly.Load(path).CreateInstance(path + "." + dbName + "UserManager");

}

}

所有的判斷都是在運行時由反射機制實現的，其靈活性可謂無敵，某天需要加入 Access 資料庫操作的 DAL 一系列對象，只需要在設計時實現 IDAL 介面，命名規範。切換資料庫時，在 DALFactory 中修改 path 和 dbName 即可。其缺點 1 ，反射的效率低，不過現在的電腦，這點可以忽略；缺點 2 ，易出錯，細心一點兒就行了。

以上都是一些簡單原廠模式的使用，碰上 DAL 層對象數量巨大，一個使用反射的 DALFactory 也不一定能夠輕鬆維護。怎麼辦呢？每個 DAL 對象相當於工廠裡邊一個產品的話，管理起來肯定麻煩，如果把產品整理成 產品線 進行管理，維護時肯定要輕鬆一些。

public abstract class AbstractFactory //抽象工廠

{

//產生對象的生產線聲明

public abstract IUserManager CreateUserManager();

public abstract IStudentManager CreateStudentManager();

//選擇對應的工廠

public static AbstractFactory ChooseFactory()

{

string dbName = ConfigurationManager.AppSettings["DBName"];

AbstractFactory factory = null;

if(dbName == "SQL")

factory = new SQLDALFactory();

if(dbName == "Oracle")

factory = new OracleDALFactory();

return factory;

}

}

// SQL 產品線

public class SQLDALFactory : AbstractFactory

{

public override IUserManager CreateUserManager()

{

return new SQLUserManager();

}

public override IStudentManager CreateStudentManager()

{

return new SQLStudentManager();

}

}

// Oracle 產品線

public class OracleDALFactory : AbstractFactory

{

public override IUserManager CreateUserManager()

{

return new OracleUserManager();

}

public override IStudentManager()

{

return new OracleStudentManager();

}

}

定義好產品線和對應的產品，BLL 層取得對應對象時，仍然使用介面的引用指向對應的 DAL 對象

IUserManager ium = AbstractFactory.ChooseFactory().CreateUserManager();

其他照舊。

維護時，切換對象的操作只需要在 AbstractFactory 中切換抽象工廠引用的實體工廠即可。