最近對多層設計實現和.Net產生了興趣，從而研究了一下比較著名的多層範例程序――PetShop，現在的版本是3.0，和以前的版本從設計上已有一定的區別，應該是和Java的Petshop設計相當。
關於一些Microsoft PetShop的來由、如何安裝，所表現業務流程，數據庫表結構等基本的信息的資料請大家參考下面文章
http://msdn.microsoft.com/library/en-us/dnbda/html/bdasamppet.asp 另外建議先看一下這篇文章：
http://msdn.microsoft.com/library/en-us/dnbda/html/petshop3x.asp(如有格式問題本文可
http://www.surfsky.com/bbs/myfiles/MSPetShop3.0%20Report.doc下載)
本文將以設計和實現緊密結合的方式來分析，這也是我們廣大實踐型的軟件開發人員的風格。先看一下設計圖和具體實現VS.NET工程的表格。
MSPetShop 3.0系統結構圖：
從圖中可以看到系統大體分爲Presentation,Business Logic,Data Access三層，每層中又有子層。每層（也包括子層）各司其職，又互相協作，本文順序以此圖爲準，從下到上分析。
對應上圖，具體的.NET Project實現列表（借用MS文章中的列表不用翻譯了吧）
Project
Purpose
BLL
Home for business logic components
ConfigTool
Administration application used to encrypt connection strings and create event log source
DALFactory
Classes used to determine which database access assembly to load
IDAL
Set of interfaces which need to be implemented by each DAL implementation
Model
Thin data classes or business entities
OracleDAL
Oracle specific implementation of the Pet Shop DAL which uses the IDAL interfaces
Post-Build
Project to run post compile actions such as adding assemblies to the GAC or COM+
Pre-Build
Project to remove assemblies from the GAC or unregister assemblies from COM+
SQLServerDAL
Microsoft SQL Server specific implementation of the Pet Shop DAL which uses the IDAL interfaces
Utility
Set of helper classes including a wrapper for the DPAPI
Web
Web pages and controls
Solution Items
Miscellaneous items used to build the application such as Pet Shop.snk key file used to sign application assemblies
另外我寫這篇文章時是一邊看源碼一邊寫，所以建意大家最好安裝一個Petshop3，因爲時間倉促，水平有限，如我有不對之處請給我發Email更正。email:[email protected] qq:364941
首先我們來看一下DAL層。
一：Data Access Layer:
1 PetShop.Utility如下圖：（上表中Utility爲其實現工程）
正如上表所描述，這個名字空間有兩個類一個是ConnectionInfo用於加密解密數據庫連接信息，另一個DataProtector調用了Crypt32.dll和kernel32.dll實現一些底層數據安全操作，這個類要在下面的PetShop.XXXDAL名字空間中調用，可見Petshop.Utility只是起到的是數據訪問輔助工具的作用。
2 PetShop.SQLServerDAL ――系統結構圖中DAL層中的SqlServer DAL子層實現
SqlHelper類實際上是封裝了關於此係統中數據庫操作訪問的一些常用功能，其中它還會調用上面的PetShop.Utility中的ConectionInfo類方法加密解密連接字符串，如：ConnectionInfo.DecryptDBConnectionString方法。SqlHelper類是基於Microsoft Data Access Application Block for .NET。這個東西是用來幫助用戶更好的在.NET的訪問數據。如MS一段話：Are you involved in the design and development of data access code for .NET-based applications? Have you ever felt that you write the same data access code again and again? Have you wrapped data access code in helper functions that let you call a stored procedure in one line? If so, the Microsoft® Data Access Application Block for .NET is for you。其實可以自已寫一個類似SqlHelper的東西，以實現一般化的對數據庫的操作，以在各項目中重用，當然也可以使用現在的MS爲你做好的這個SqlHelper或是Microsoft® Data Access Application Block for .NET，避免不同項目中總是寫同樣的重複的數據庫訪問程序。有時間最好還是看一下SqlHelper的具體程序實現思路以及所提到的那個Microsoft Data Access Application Block for .NET。不過這裏我們的SqlHelper應該只是部分實現。更全面信息請參看
http://msdn.microsoft.com/library/en-us/dnbda/html/daab-rm.asp Account類對用戶帳戶進行操作如Insert,Update,SignIn，其中這些對數據庫的操作，使用了上面的SqlHelper類來實現。另外Inventory和Order,Product,Profile和Account類的都是同樣對數據庫相關表進行操作，程序風格一致，這些類中對數據庫的操作都是通過此名字空間下的SqlHelper類進行的，例如，下面語句：
private const string SQL_INSERT_SIGNON = “INSERT INTO SignOn valueS (@UserId, @Password)”;
private const string PARM_USER_ID = “@UserId”;
private const string PARM_PASSWORD = “@Password”;
來定義一個sql語句，以及聲明其中可變參數，然後像下面這樣用SqlHelper類的合適的方法執行：
SQLHelper.ExecuteNonQuery(trans, CommandType.Text, SQL_INSERT_SIGNON, signOnParms);
最後在SQLHelper.ExecuteNonQuery實現中，再調用ado.net中的相關類最終執行對數據庫的操作，可見SqlHelper在這裏又封裝了一下ado.net相關類以優化數據操作。正如SqlHelper.cs中註釋提示：The SqlHelper class is intended to encapsulate high performance, scalable best practices for common uses of SqlClient.下面是SqlHelper. ExecuteNonQuery的實現內容：
public static int ExecuteNonQuery(string connString, CommandType cmdType, string cmdText, params SqlParameter[] cmdParms) {
//注：運行時cmdText的實參就是SQL_INSERT_SIGNON
SqlCommand cmd = new SqlCommand();
using (SqlConnection conn = new SqlConnection(connString)) {
PrepareCommand(cmd, conn, null, cmdType, cmdText, cmdParms);
int val = cmd.ExecuteNonQuery();
cmd.Parameters.Clear();
return val;
}
}
另外Inventory和Order,Product,Profile和Account類的聲明都是像public class Account : IAccount這樣實現某個相關的接口，像IAccount這樣的接口是在PetShop.IDAL中聲明的，見後面介紹。
3 PetShop.OracleDAL ―――系統結構圖中DAL層的OracleDAL子層實現
個人認爲結構應該同上面的PetShop. SQLServerDAL，另外SqlHelper變成了OraHelper，在OraHelper中當然具體實現了對特定的Oracle數據庫的聯接操作，看一下源程序很明顯原來的 SqlCommand cmd = new SqlCommand(); 變成了OracleCommand cmd = new OracleCommand();。
注意一下：在系統結構圖中的DAL層還有兩個XXX DAAB的子層，它們對應的實現在哪裏呢？ 下面對應一下：
以下是左邊是圖中DataAccessLayer的各部分，右邊是具體實現所在名字空間或類
SqlServer DAL――PetShop.SQLServerDAL名字空間
Sql DAAB――PetShop.SqlServerDal.SqlHelper類
Oracle DAL――PetShop.OracleDAL名字空間
Oracle DAAB――PetShop.OracleDAL.OraHelper類
4 PetShop.IDAL數據訪問接口――對應系統結構圖中DAL Interface
接口是一種系列‘功能’的聲明或名單，接口沒有實現細節，如下接口IAccount定義也可以看出IAccount只有聲明：
using System;
using PetShop.Model;
namespace PetShop.IDAL
{
// Inteface for the Account DAL
public interface IAccount
{
// Authenticate a user
AccountInfo SignIn(string userId, string password);
/// Get a user’s address stored in the database
AddressInfo GetAddress(string userId);
/// Insert an account into the database
void Insert(AccountInfo account);
/// Update an account in the database
void Update(AccountInfo Account);
}
}
您只需要調用接口，而不用管接口是如何實現的那麼接口沒有實現，調用它有什麼用？實際上接口的實現是由某個類來做的，那麼這裏的IAccount接口是由PetShop.SqlServerDAL.Account類或是PetShop.OracleDAL.Account類來實現的，從他們的定義可以看到：
public class Account : IAccount {…….}
爲什麼是兩個類都實現同一接口又是‘或’呢？因爲這裏使用接口的目的就是爲了統一‘外觀’，當上層BLL層調用此接口方法時不用知道這個接口由哪個類實現的。那誰來確定使用哪個類的實現？請再看下面。
（PetShop.IDAL下的其它接口和IAccount一樣，故在此略過。）
5 PetShop.DALFactory數據訪問工廠
工廠模式是設計模式的一種，以我理解就像Factory這個詞一樣，對於用戶來說，工廠裏產品如何生產的你不用知道，你只要去用工廠裏生產出來的東西就可以了。MSPetShop3.0用工廠模式來實現了對SqlServer和Oracle數據庫訪問的操作，而用戶（business Logic Layer）不用知道也不用關心後臺用的是哪一種數據庫，它只要用接口就行了，接口中定義了要用的方法，當調用接口時會根據具體的情況再去調用底層數據訪問操作。而現在這個DALFactory就是關鍵，當BLL層要操作數據庫時，DALFactory會根據具體情況再去使用本文上面介紹的SqlServerDAL和OracleDAL中的一個。這樣系統上層只管調用，而下層來實現細節，上級只管發號施令，下級去幹活。對於上層來說實現細節被隱藏了。
那麼DALFactory是如何決定應該用SqlServerDAL還是用OracleDAL的呢？我們接着分析。
以下是PetShop.DALFactory.Account類的實現：
namespace PetShop.DALFactory {
/// <summary>
/// Factory implementaion for the Account DAL object
/// </summary>
public class Account
{
public static PetShop.IDAL.IAccount Create() //<<<<ß----這裏返回接口
{
/// Look up the DAL implementation we should be using
string path = System.Configuration.ConfigurationSettings.AppSettings[”WebDAL”];
string className = path + “.Account”;
// Using the evidence given in the config file load the appropriate assembly and class
return (PetShop.IDAL.IAccount) Assembly.Load(path).CreateInstance(className);
}
}
}
以下則是web.config中<appSettings>節點中的一部分：
<add key=”WebDAL” value=”PetShop.SQLServerDAL” />
<add key=”OrdersDAL” value=”PetShop.SQLServerDAL” />
<add key=”Event Log Source” value=”.NET Pet Shop” />
上面的Create()方法返回IAccount接口，用System.Configuration.ConfigurationSettings.AppSettings[”WebDAL”];則可以得到Web.config的<appsettings>節點中的關於系統中應該使用哪個數據訪問層（SqlserverDAL還是OracleDAL）的信息。因爲我在安裝PetShop3.0時選擇的是Sqlserver所以在此是：value=”PetShop.SQLServerDAL”，如果用的是Oracle那就是value=”PetShop.OracleDAL” 了吧！而且這個文件也應該是可以更改的。接下來className=path+”.Account”返回的應該是PetShop.SQLServerDAL.Account,然後再用Assembly.Load加載PetShop.SQLServerDAL.dll，同時創建PetShop.SQLServerDAL.Account的實例，並以接口（PetShop.IDAL.IAccount）類型返回。這樣BLL調用IAccount接口時就會用PetShop.SQLServerDAL.Account類的實現代碼。（回上面第4再看一下）
看！這樣根據系統當前Web.config文件的配置描述（這也應該是系統運行時實際的配置），BLL層只要像下面這樣：
// Get an instance of the account DAL using the DALFactory
IAccount dal = PetShop.DALFactory.Account.Create();
AccountInfo account = dal.SignIn(userId, password);//<<ß----看看上面第4點的IAccount接口
就可以直接調用接口方法通過下層DAL層操作數據庫了（在此具體爲用戶賬號相關操作），而BLL層並不用知道應該通過SqlserverDAL還是OracleDAL訪問數據庫，這由都DAL Factory決定，你用的是什麼數據庫以及底層細節，更不用BLL知道，這樣做的好處是對於BLL層以及更上層的程序不會或很少機率會因爲底層程序變動影響，因爲BLL層中調用接口就行了，只要那個接口定義沒變，一切仍然OK.
6 PetShop.ConfigTool
首先在../Microsoft/PetShop/ConfigTool/中有一個app.config文件，看一下其中內容，分別定義了兩種數據庫的聯接字符串，在app.config中有一行 <add key=”WebConfigFileLocation” value=”Web/Web.config” /> 則標識出給asp.net程序使用的web.config配置文件的相對位置。然後看一下PetShopConnectionString的EncryptConnectionString方法的源碼，這個類中先是從當前目錄的app.config文件中讀出web.config文件的位置，如下：
public static readonly string CONFIGFILE = ConfigurationSettings.AppSettings[”WebConfigFileLocation”];
然後語句
XmlDocument doc = new XmlDocument();
doc.Load(CONFIGFILE);
加載Web.config文件，最後將加密的連接字符串寫入Web.config對應的XML節點中。以供Asp.net應用程序使用。其中的加密還是使用PetShop.Utility。
而ConfigConsole，調用PetShopConnectionString類EncryptConnectionString執行對聯接字符串進行加密。另外PetShopEventLog類也是在ConfigConsole中使用的。用於記錄程序日誌。
所以在最後部署時Web.config的連接字符串是加密的。
7 PetShop.Model 業務實體模型
http://www.surfsky.com/bbs/myfiles/7.bmp
這個本來想在分析BLL層時再說，但是在SqlServerDAL和OracleDAL中都使用了這些Model，無論怎麼樣，上層的程序執行最終結果都是要操作數據庫，而數據庫是關係型，不是面向對象的，那就得把平面的‘表’結合業務規則抽象成類，這樣想辦法讓上層(BLL及以上)以爲自已在操作類而不是數據庫表，從而使‘它們’感覺沒有數據庫的存在，上層只管面向對象編程就可以了。類似現在所說的O-R MAPPING，但O-R MAPPING比這種簡單的數據到對象的持久化要複雜。據說可以在表結構有變化的情況下，上層應用程序代碼不用更改，只要改O-R MAPPING的相關設置就可以了。
上面第2節中已看到Petshop的SqlServerDal和OracleDal中定義的sql語句，然後根據上層的調用，把sql語句傳給SqlHelper執行，再來看看SqlServerDal的一段程序：
private void SetAccountParameters(SqlParameter[] parms, AccountInfo acc) {
parms[0].value = acc.Email;
parms[1].value = acc.Address.FirstName;
parms[2].value = acc.Address.LastName;
parms[3].value = acc.Address.Address1;
parms[4].value = acc.Address.Address2;
parms[5].value = acc.Address.City;
parms[6].value = acc.Address.State;
parms[7].value = acc.Address.Zip;
parms[8].value = acc.Address.Country;
parms[9].value = acc.Address.Phone;
parms[10].value = acc.UserId;
}
parms[x]就是那些有聲明爲常量的有參數的Sql語句中的參數，這裏用Model中的AccountInfo的各Field和這些參數Mapping。所以對於BLL層，只知道這些Model就可以了，反正最後在SqlServerDAL或是OracleDAL中Model的成員們會Mapping到參數中以存取數據庫（爲什麼不直接Mapping到數據集的字段呢？我想應該是因爲這裏數據庫操作直接給SqlHeper的原因，不然就沒必要用SqlHelper了。於是才又多了圖中的xxx DAAB層，這樣Mapping給參數再傳給DAAB來處理）
Data Access Layer總結：
DAL完成數據庫訪問任務，上層(BLL)直需調用接口即可，不用知道具體訪問細節，用Factory模式來實現，使用運行時讀取web.config的方法來得到連接配置信息，最後選用SqlServerDAL或OracleDAL之一的相對具體子層，同時使用SqlHelper或OraHelper之一來完成數據庫操作。