skmFAQs.NET：一個 ASP.NET FAQ 應用程序

本頁內容

	簡介
	ASPFAQs.com：實例研究
	skmFAQs.NET 的設計目標
	安裝和設置 skmFAQs.NET
	skmFAQs.NET 入門
	小結

簡介

因為 Internet 和萬維網已經變得越來越普遍并且越來越便于非計算機專業人士使用，所以出現了各種各樣的 Web 應用程序，以支持各種形式的通信。它們中最受歡迎的應用程序之一是網絡日記，它提供了個人在 Internet 上發表作品的方便手段。另一個廣受歡迎的通信應用程序是 Wiki，它在 Internet 上建立了一種所有人都可以投稿的虛擬白板。

上述技術以及類似技術的目標是讓使用雙方能夠互相通信，并且可以按照通信中涉及的雙方的人數多少對它們進行分類。有三種可能的發送者和接收者：

不同的應用程序允許對上述類型的人數多少進行不同配對。例如，電子郵件和即時消息提供了個人對個人通信，而電子郵件討論組或聊天室則提供了個人對定義的用戶組通信。大多數網絡日記都支持從個人到任何訪問者的通信，盡管可以將網絡日記配置為只允許定義的用戶組訪問（例如，公司 Intranet 上的內部網絡日記）。另一方面，Wikis 設計為允許任何人之間進行通信。

一種將網絡日記與 Wiki 模型結合起來的通信模型允許定義的用戶組與任何人通信。這與 Wiki 類似，因為很多用戶可以投稿；但與 Wiki 不同的是，它對誰可以投稿（有時還包括他們的投稿方式）施加限制。大型 Web 站點（尤其是那些包含大量內容的站點）通常使用 Content Management System (CMS) 軟件提供這一模式的通信。然而，CMS 軟件通常非常昂貴，并且通常包含一組只有經常發布和更新大量內容的站點才需要的功能。這樣的軟件對于非營利性公司或俱樂部而言通常有點兒奢侈。這些規模較小的用戶可能具有一個面向公眾的 Web 站點，他們希望允許多個雇員或成員對其進行維護（而不是將此類責任強加在一個人的身上），但不需要具有專業 CMS 系統的能力。

對于上述產品，已經存在優秀的開放源碼 ASP.NET Web 應用程序。在網絡日記領域，有 Community Server；對于 Wikis，請參見 FlexWiki；DotNetNuke 和 Rainbow 是 ASP.NET CMS 項目。但是，允許定義的用戶組與任何人進行通信的 Web 應用程序仍然有用武之地。為了滿足這一需要，我著手開發了一個開放源碼 Web 應用程序，稱為 skmFAQs.NET。skmFAQs.NET 的高級目標是使任何人都能夠容易地在其 Web 站點中添加和集成“常見問題”(FAQ) 部分，并且可以由預定義的用戶組進行更新。

在本文中，我們將分析 skmFAQs.NET 的設計目標，并且探討它的體系結構是如何幫助實現這些目標的。我們還將快速瀏覽 skmFAQs.NET 的功能，并且逐步演練設置和安裝過程。在探討 skmFAQs.NET 的設計目標之前，讓我們首先看一下 ASPFAQs.com（一個 ASP 和 ASP.NET FAQ Web 站點）的實例研究。這樣的分析可以突出說明任何打算允許定義的用戶組聯機發布信息的實際 Web 應用程序的一些難題和所需的功能。

ASPFAQs.com：實例研究

作為大量 ASP 和 ASP.NET 書籍、雜志文章和聯機文章的作者，我每天都會在我的收件箱中收到一連串的技術問題。盡管提出的每個問題都有其自己的難點，但有很多常見的問題 — 實際上，這樣的問題是如此之多，以至于我在 2000 年 9 月份決定創辦 ASPFAQs.com，以充當一些最常見問題的答案的公共知識庫。

最初，ASPFAQs.com 只是充當 FAQ 和及其答案的數據庫前端。該數據庫開始時只有兩個表：Categories 表和 FAQs 表；后者存儲每個 FAQ 的記錄、它的答案以及它所屬的類別。當我希望添加新的 FAQ 時，我就會訪問特定的 Web 頁，以便輸入問題、指定類別和提供答案。

當只有單個投稿人時，這可以足夠好地工作；但很快，經常訪問 ASPMessageboard.com 的用戶產生了張貼常見留言板問題的答案的興趣。這些投稿人首先通過電子郵件向我發送問題和答案，然后由我通過 Web 界面將它們插入。而且，當其中一個投稿人希望通過補充或編輯答案來完善其工作時，我還充當了中間人的角色。

最終，ASPFAQs.com 演變為一個更為成熟的應用程序，它為投稿人分配了登錄名，以便他們可以自行添加和編輯 FAQ，而無需我的干預。這就向數據庫架構中添加了一個新表 — Users，它為系統中的每個用戶帳戶提供了一個記錄。每個用戶帳戶都由下列三個可能的選項之一賦予了特定的訪問級別：

我將我自己的用戶帳戶標記為唯一的管理員帳戶，然后基于其他用戶的以前跟蹤記錄，向他們分發受信任的投稿人和不受信任的投稿人狀態。

盡管 ASPFAQs.com 多年來不斷演變，但創建新 FAQ 仍然是一項相當深奧的操作，因為 ASPFAQs.com 的 Web 界面用特定標記（HTML 的子集）接受答案。這意味著投稿人必須學習這一標記，以便對他們的貼的格式設置具有更精細的控制。很多 Wiki 引擎用戶也會遇到這一類似的問題。

回想起來，ASPFAQs.com 有很多非常棒的功能，但也有許多有待改進的地方。它的一些優點包括：

主要的改進方面包括：

有了創建和維護 ASPFAQs.com 的實際經驗，我對制定 skmFAQs.NET 的設計目標充滿信心。

skmFAQs.NET 的設計目標

在創建應用程序時，我通常會經歷一個迭代的過程來制定設計目標。我首先制定少數幾個非常高級的目標。在制定、權衡和接受這些目標以后，我就會將這些高級目標分解為更為具體的目標。該過程可能會經歷多次迭代，直到我手頭具有了一些非常具體的任務為止。

在創建 skmFAQs.NET 時，我決定使其可能滿足下列三個高級目標：

有了上面列出的三個高級目標以后，下一步是將這些目標分解為更為具體的目標。

使 skmFAQs.NET 易于使用

我首先從“確保 skmFAQs.NET 易于使用”這一目標開始，并且寫下了有關如何實現這一目標的想法。有兩種不同類型的 skmFAQs.NET 用戶：內容創建者和頁開發人員。內容創建者是那些通過 Web 站點界面與應用程序交互的用戶，他們向站點中添加新的 FAQ。另一方面，頁開發人員是那些必須將 skmFAQs.NET 合并到現有 Web 應用程序中或者需要自定義 skmFAQs.NET 的功能或外觀的用戶。顯然，對于上述兩類用戶而言，使 skmFAQs.NET 易于使用的目標大為不同。

經過一番苦思冥想，可以制定出這兩類用戶的具體目標，其中一些目標有助于另外兩個高級目標的實現。通過 Web 界面添加 FAQ 的用戶的目標包括：

上述一些比較具體的目標看起來可能是如此直觀，以至于不值得將它們列出來。但是，我發現這樣做有助于枚舉那些甚至極為明顯的目標和任務，部分原因在于它們可以幫助發現一些不這樣做就可能得不到實現的功能。例如，進一步鉆研上面列出的第二個目標，可以迫使我以批判的態度考慮哪些功能可以使向另一個人的 FAQ 中追加內容成為真正毫不費力的任務。另外，列出那些即使是顯而易見的需求，可以提供一個完整的視野，而這又有助于確定時間估計、設置里程碑以及評價進度。

頁開發人員的更為詳細的目標包括：

由于本文的目的是概述 skmFAQs.NET，而不是提供深入的功能性規范文檔，因此我們就不再進一步探討這些可用性目標了。當我們在本文的其余部分更詳細地分析 skmFAQs.NET 的時候，您將了解有助于實現這些目標的功能和設計決策。

實現細粒度的訪問權利

基于我從 ASPFAQs.com 中獲得的經驗，我希望在 skmFAQs.NET 中對訪問權利提供更為精細的控制級別。在設計該系統時，我希望顧及一個用例，即大型站點可以使用單個 skmFAQs.NET 應用程序實例來設置多個獨立的 FAQ 部分。

Project Distributor 是一個 Web 站點，它充當小型代碼項目的儲存庫。用戶可以在 Project Distributor 中創建帳戶，并在那里宿主他們的應用程序。對于這樣的 Web 應用程序，讓每個用戶具有對應于其軟件項目的 FAQ 會很有用。每個用戶的 FAQ 部分從任何可能的意義來說都與其他用戶分隔：

為了啟用類似的方案，訪問權利是按照類別實現的。要實現此類系統，需要為 Project Distributor 中的每個項目創建一個 FAQ 類別，并且使合適的用戶收到所需的權利。（當使用 skmFAQs.NET API 在該系統中創建新用戶帳戶時，可以用編程方式完成該工作。）

決定系統中應用權利的實體的粒度只是解決了難題的一半；另一半是指定可以將哪組權限應用于每個實體�？梢詫⒏鞣N各樣的權限應用于類別，包括執行下列操作的能力：

在一個極端的情況下，可以為每個類別的每個用戶設置這些權限。一個不那么詳細的方案會將相關權限組合到角色中，并且只允許按照用戶、類別來分配角色。這兩種極端的方案代表在表達性和可用性之間進行的經典折衷；因為我為 skmFAQs.NET 制定的主要設計目標之一是易于使用，所以我決定選擇基于角色的方法。因此，該系統具有四個預定義的角色：

圖 1 顯示 skmFAQs.NET“Permissions Administration”頁的屏幕快照，只有管理員才能訪問該頁。在該屏幕中，管理員可以從下拉列表中選擇用戶，然后為該系統中的任何類別指定角色。

圖 1. 權限管理

構建可擴展的且可自定義的應用程序

在三個高級設計目標中，重點是第三個也就是最后一個目標：確保 skmFAQs.NET 是可擴展的且可自定義的。在我過去使用預生成的商業 Web 應用程序的經歷中，我已經忍受了大量挫折和痛苦，試圖對相當呆板的應用程序進行調整以適合我的特定需求。為了提供能夠滿足不同客戶的獨特要求的應用程序，我將精力集中于下列兩個目標：

skmFAQs.NET 的體系結構模仿了 Community Server 論壇（為 ASP.NET Forums 提供動力的論壇軟件）所使用的體系結構，并且由下列四個層組成：

圖 2 顯示 skmFAQs.NET 體系結構的圖形表示形式。

圖 2. skmFAQs 體系結構

表示層的 ASP.NET 頁包含 FAQ 應用程序功能所必需的頁。有下列兩類頁：所有用戶都可以訪問的頁，如那些顯示 FAQ 類別列表并顯示特定 FAQ 的頁；以及那些只有注冊用戶可以查看的頁，包括用于添加和編輯 FAQ、創建用戶帳戶以及設置權限等的頁。skmFAQs.NET 還附帶了一些經過編譯的自定義服務器控件，以便減輕頁開發人員的負擔。例如，要在頁上顯示 FAQ，只需在該頁上放置一個 ShowFAQ Web 控件，并且將它的 FAQID 屬性設置為要顯示的 FAQ 的 ID。圖 3 通過 Visual Studio .NET“Design”選項卡顯示 ShowFAQ Web 控件；您可以通過該控件的格式屬性（BackColor、ForeColor、Font、AnswerStyle、QuestionStyle 等）自定義格式設置，并且在必要時通過 QuestionTemplate 和 AnswerTemplate 模板來非常明確地定制呈現的標記。

圖 3. 設計時的 ShowFAQ Web 控件

應用程序邏輯層包含應用程序的編程 API。表示層中的所有頁和控件都直接與應用程序邏輯層通信（與直接訪問數據庫相反）。應用程序邏輯層將 API 劃分為包含靜態方法的相關類 — CategoryAPI、FAQAPI、PermissionAPI 等。另外，還有一組業務對象，它們是對系統中的邏輯實體進行抽象定義的類。這些業務對象是在表示層和應用程序邏輯層之間的通信中使用的抽象。例如，存在一個 Category 類，它包含 FAQ 類別所固有的屬性（CategoryID、Name、Description 等）。很多 CategoryAPI 方法（如 AddCategory(Category)）接受并且/或者返回 Category 實例。

抽象數據訪問層是作為 abstract 類實現的，它定義了具體的派生提供程序必須實現的大量 abstract 方法。另外，抽象數據訪問層還為所有提供程序所共有的那些任務（如填充業務對象的實例）提供了實際的已實現的方法。skmFAQs.NET 附帶了一個內置的提供程序 — SqlDataProvider，它通過將 Microsoft SQL Server 作為它的后援存儲區與其進行交互，擔任了具體提供程序的角色。

注該提供程序模型設計模式在 ASP.NET 2.0 中得到了頻繁使用。如果您不熟悉該設計模式，則我建議您閱讀 Rob Howard 的“Provider Model Design Pattern and Specification”，這是一個由兩部分組成的文章系列，其中介紹了該提供程序模型設計模式以及如何在 ASP.NET.x 中實現它：部分 1 和部分 2。

安裝和設置 skmFAQs.NET

skmFAQs.NET 可以安裝在任何支持 ASP.NET .x 的 Web 服務器上。正如前面提到的那樣，skmFAQs.NET 隨附了一個用于 Microsoft SQL Server 數據庫的數據提供程序，因此建議您將您的站點連接到 SQL Server 數據庫。如果您不具有可由您隨意使用的 SQL Server，則可以創建一個數據提供程序，以利用不同的數據存儲區（Microsoft Access、XML 文件等）。假設您的站點滿足技術要求，則可以在幾分鐘之內完成安裝和設置 skmFAQs.NET 的工作。

在開始安裝 skmFAQs.NET 之前，您首先需要訪問 skmFAQs.NET Download Page。下載內容包括：

在下載 skmFAQs.NET 時， 步是設置數據庫，這涉及到運行所提供的 SQL 腳本。這些 SQL 腳本不僅創建需要的表、視圖、存儲過程等，而且還用一些初始數據填充表。特別地，還通過用戶名 Admin 和密碼 admin 創建單個用戶帳戶。應該盡快更改這一組合 — 無論是在預安裝期間更改，通過更改 SQL 腳本中的用戶名/密碼進行更改，還是以后通過 SQL 企業管理器或者通過演示 Web 站點的 Administration 頁進行更改。

在創建了數據庫元素并且用初始數據填充這些元素以后，下一步就是將演示 Web 站點推送到 Web 服務器上：如果您要將該站點移至遠程服務器上，則請簡單地使用 FTP 或 Visual Studio .NET 中的“復制 Web 站點”功能；如果您要在本地進行開發，則只需配置 IIS 以創建一個指向解壓縮的演示 Web 站點位置的新虛擬目錄。演示 Web 站點的 Web.config 文件包含一個 <skmFaqSettings> 元素（如下所示），它需要更新以包含切合數據庫服務器和 Web 站點的信息。

<skmFaqSettings 
defaultProvider="SQL" 
 showCategoryUrl="~/ShowCategory.aspx?ID={0}" 
 showFAQUrl="~/ShowFAQ.aspx?ID={0}"
 siteTitle="skmFAQs.NET"
 adminEmail="<i>CHANGE@ME.COM</i>"
>
<!-- Set the connectionString property to the 
   connection string to the database where you ran the
   included SQLscripts and have created the skmFAQs.NET
   database elements...
   For databaseOwner, put the name of the owner of the 
   database elements. Typically this will be the
   username with which you connected to the database server 
   to run the SQLscripts... -->
<providers>
 <add name="SQL"
      type="FAQComponents.Provider.SqlDataProvider, FAQComponents"
      connectionString="<i>PUT YOUR CONNECTION STRING HERE</i>"
      databaseOwner="dbo" />
</providers>
</skmFaqSettings>

在 部分中，更新 siteTitle 和 adminEmail 屬性值以反映 Web 站點的標題、時區和您的電子郵件地址。showCategoryUrl 和 showFAQUrl 屬性指定分別負責顯示某個類別的 FAQ 和顯示特定 FAQ 的 ASP.NET 頁的路徑。演示 Web 站點使用頁名稱 ShowCategory.aspx 和 ShowFAQ.aspx，因此，在使用演示 Web 站點時，請將這些設置保留原樣。但是，如果您需要自定義 skmFAQs.NET 并希望使用不同的頁來顯示類別或 FAQ，則請在這里更新頁 URL。defaultProvider 屬性指定應該使用 部分中的哪個提供程序。

子元素包含有關可用的數據提供程序的詳細信息，以及與該提供程序相關的詳細信息。默認情況下，skmFAQs.NET 附帶了一個名為 SQL 的提供程序，它提供了指向 Microsoft SQL Server 數據庫的連接。在 元素中，說明了 SQL 提供程序的詳細信息，包括該提供程序的 type（Namespace.ClassName、AssemblyName）、connectionString 和 databaseOwner。當然，您需要用您數據庫的連接字符串更新 connectionString 屬性。

skmFAQs.NET 入門

在已經配置 部分之后，您就應該能夠訪問 FAQ 演示 Web 站點。但是，該站點不會令人非常興奮，因為在系統中沒有 FAQ。不過，您可以通過轉到位于演示 Web 站點的 Admin 子目錄中的 Administration 頁（例如，如果您在計算機上的虛擬目錄 FAQs 中安裝了演示站點，則 Administration 頁位于 http://localhost/FAQs/Admin），創建新的 FAQ。圖 4 顯示 Administration 頁主菜單的屏幕快照。

注當您登錄 Administration 頁時，系統將提示您輸入用戶名和密碼。在設置 skmFAQs.NET 的初始數據時，創建了一個用戶名為 Admin 且密碼為 admin 的帳戶。

圖 4：Administration 頁

正如圖 4 顯示的那樣，存在各種對應于 Administrator、FAQ Editor 和 Contributor 的選項。由于我已經以 Administrator 的角色登錄，所以我可以查看下列所有選項；但是，FAQ Editor 只能查看 FAQ Editor 和 Contributor 選項，而 Contributor 只能查看 Contributor 選項。

Administrator 選項包括：

FAQ Editor 和 Administrator 都可以使用的 FAQ Editor 選項包括：

投稿人（包括受信任的和不受信任的）只能任意使用一個選項：FAQ Administration�！癋AQ Administration”屏幕使用戶可以創建、編輯或刪除他們自己的 FAQ。Contributor 和 FAQ Editor 只能在他們具有權利的那些類別中創建 FAQ；Administrator 可以在系統中的任何類別中創建 FAQ。

我從 ASPFAQs.com 中獲得的教訓之一是使創建 FAQ 盡量容易。理想情況下，不應該要求用戶了解特殊的語法，如 HTML 或 Wiki 關鍵字。我決定利用 John Dyer 的 FreeTextBox 控件，它提供了功能豐富的 WYSIWYG 文本編輯器。圖 5 顯示創建新 FAQ 的屏幕快照：

圖 5. 創建新的 FAQ

skmFAQs.NET 中的 FAQ 包含一個問題以及一個或多個 FAQ 部分。FAQ 部分是答案的一部分。在創建新的 FAQ 時，所提供的答案是 個 FAQ 部分。但是，其他投稿人可能希望對 FAQ 的答案進行補充。在查看 FAQ 時，已登錄的用戶將在該 FAQ 的底部看到 Contribute to this FAQ's Answer 鏈接。單擊該鏈接可以將他們帶到一個頁，他們可以在那里向該 FAQ 提供一個附加的 FAQ 部分。（僅當該用戶具有在該 FAQ 的類別中創建 FAQ 的權限時，才會顯示該鏈接；除非由 Administrator 或 FAQ Editor 批準，否則，Untrusted Contributor 的 FAQ 補充內容不會顯示。）

小結

本文提供了 ASPFAQs.com 的一個實例研究，然后概述了使定義的用戶組可以聯機發布信息的 skmFAQs.NET（一個 ASP.NET .x 應用程序）。skmFAQs.NET 的目的是維護常見問題列表 — 這是很多 Web 站點的需求。skmFAQs.NET 的設計目標是既易于使用，又可以擴展。