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 在该系统中创建新用户帐户时，可以用编程方式完成该工作。）

决定系统中应用权利的实体的粒度只是解决了难题的一半；另一半是指定可以将哪组权限应用于每个实体。可以将各种各样的权限应用于类别，包括执行下列操作的能力：

在一个极端的情况下，可以为每个类别的每个用户设置这些权限。一个不那么详细的方案会将相关权限组合到角色中，并且只允许按照用户、类别来分配角色。这两种极端的方案代表在表达性和可用性之间进行的经典折衷；因为我为 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。“FAQ 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 的设计目标是既易于使用，又可以扩展。