ProviderBase框架概要

學習技巧: 5顆星
學習條件:
1. 物件導向編程(OOP)基礎
2. OOA的Design Pattern基本概念
3. IIS基本概念
4. ASP.NET與C#編程基礎
5. UML視圖基礎
ProviderBase是自從NET. Framework 2.0後新增的功能, 他是相當核心的底層元件, 利用它可以封裝各式各樣的ASP.NET機能, 由於他太過底層. 所以一般編程設計不太會去面對它. 根據MSDN文件紀載了他的結構:
public abstract class ProviderBase
顯而易見可以看出, 他是一個抽象, 而非具象結構. 在ASP.NET中有很多元件皆是實作這個抽象. 他提供了一種稱之為Provider的機制與概念, 也就是功能上的提供者. 例如我們在IIS可以看到基本的RBAC機制, 像是RoleProvider或著MembershipProvider等, 都是實作這個抽象.

上圖是從IIS建立一個Web Application在Feature View可以看到的ASP.NET項目提供的Provider部分. 這個Provider項目可以查看RBAC機制所實作的相關Provider元件, 請注意! 這些Provider元件全部都可以是屬於(IS A)ProviderBase. 為什麼我們要談到這個如此底層的機制呢? 這個原因在於在往後介紹的IIS RBAC整合, 皆會與Provider框架有關, 如果能理解這個框架服務. 對於往後在學習上也有所助益!
ProviderBase來自System.Configuration.Provider組件, 並且她是個類別, 且是abstract的, 要注意這個抽象的修飾! 一般在抽象上, 提供的方法是稀少的, 在這個ProviderBase也是如此! 目的在於給衍生類別進行擴展. 在這篇的重點就是必須要理解它的結構化形式, 我這邊拿MembershipProvider的衍生類別來說明, 來看看MembershipProvider的類別結構:
public abstract class MembershipProvider : ProviderBase
可以顯而易見看出他是一個抽象, 並且繼承於ProviderBase, 在MembershipProvider已經定義了有關RBAC的成員部份的各種簽章, 例如ChangePassword(), FindUsersByName()等, 可以看出已經有一個具體的架構了. 這些簽章固定了往後具象類別的操作, 意味著具象類別在職責上來說已經確立了他的用途, 因為父類別已經提供了多種算法簽章.

上圖是IIS的Provider項目裡面可以看到的有關MembershipProvider的具象成員, 這個具象成員是由NET. Framework提供了預設成員, 透過這個預設的物件成員, 可以輕而易舉實作簡單的RBAC機制. 這個成員來自SqlMembershipProvider的具象, 來看看這個具象類別的結構:
public class SqlMembershipProvider : MembershipProvider
可以看出他是直接實作MembershipProvider的抽象, 因此在類別層次上只有兩層, 這在OOP的實務設計中是相當合理的. 由於超類別已經固定了許多相關的簽章, 因此相關的具象類別必須要實做這些簽章. 微軟已經提供了預設物件成員, 因此可以直接拿來使用, 除非有特殊需求, 否則要實作上層的抽象成員是相當繁瑣的.
另外再來看看RBAC的Role組件, 他定義了有關User屬於哪類群組, RoleProvider便是屬於ProviderBase的下層抽象, 供相關具象類別使用. 來看看它的結構:
public abstract class RoleProvider : ProviderBase
RoleProvider提供有關群組建立與維護的操作, 並且固定了許多相關的簽章, 下層具象成員實作這個抽象, 必須要完全符合這些簽章算法, 概念跟MembershipProvider是一樣的.

微軟已經提供了預設的RoleProvider具象成員, 可以直接拿來使用, 不需要另外花費寶貴的時間去設計. 一般會直接去使用AspNetSqlRoleProvider來實作.
從微軟體供了兩個預設的具象Provider成員可以看到他們都是由上層抽象來實做相關的符合簽章, 這些簽章固定了算法形式. 這是一個很重要的提醒點. 由上層抽象提供相關的算法簽章, 再由各種相關的具象類別來實作. 彼此不會有任何干涉, 形成各種算法上的獨立, 而且在實務設計上, 用較小的細粒度縮小範圍, 有效在執行期間輕而易舉去替換算法物件. 沒錯! ProviderBase架構整體是一個Strategy Pattern的變形式, 差別在於它不是典型的介面(interface)設計, 由第一層到二層都是以abstract作為宣告.
Strategy Pattern是屬於Behavorial模式的一種, 他允許定出共通的算法簽章, 不同的算法實作, 這是相當有用的設計.
Strategy模式著重在服務細節或演算流程的封裝，將服務與演算法封裝為一個個的Strategy物件，讓使用服務或演算法的客戶端可以依需求抽換服務或演算法，而不用關心服務或演算法的實作方式。
一般可以搭配Factory模式來進行組合, 實現各種替換. 這個模式是相當強大的, 因此受到廣泛使用. 說文不如看圖, 不妨來看看他的UML表示.

從圖中可以看到了介面導向的設計架構, 這種相關的Service元件依賴的是抽象, 而非具象! 這顯然是相當合理的, 逼近SRP的理念是很重要, 彈性替換元件在彼此Service元件之間不會受到任何影響. 這顯然有很強的效果, 表示了較高的內聚力. 從微軟的Provider架構, 我們可以聯想成抽象的Service介面為MembershipProvider, 在這之下有相關實作的具象類別.
在IIS的Provider操作上, 我們可以輕而易舉建立自訂的Provider元件, 但是要注意一點, 他並非介面(or抽象)導向設計, 他依賴的是一個具象類別.

從上圖可以看到, 我們可以輕易從IIS GUI上直接建立自訂的Provider元件, 但是相對的, 直接依賴具象, 意味容易被具象的繼承完全綁死. 在這個SqlMembershipProvider的具象依賴, 他只能用於微軟的MS SQL資料庫系統, 無法使用在其他的database系統, 因此如果需要其他database的結合, 就必須老老實實設計MemberhipProvider原件來提供專屬功能.
這篇文件提供對於有ASP.NET編成有興趣的人, 尤其在RBAC機制上, 這是一個較簡略的介紹. 對於從事MIS相關的人員而言, 需要理解可能需要花費不少時間, 我的建議是真的沒法看懂, 可以完全跳過此篇, 在往後介紹的實務操作上, 再來直接應用. 不論如何, 透過微軟的Provider機制進行對如AD或著FTP甚至其他高度整合, 可以提供更具powerful的管理架構.