skmFAQs.NET：一个 ASP.NET FAQ 应用程序

最新推荐文章于 2024-11-06 11:17:40 发布

weixin_30677073

最新推荐文章于 2024-11-06 11:17:40 发布

阅读量104

点赞数

文章标签：数据库设计模式后端

原文链接：http://www.cnblogs.com/kaixin110/archive/2007/12/21/1008687.html

版权

(January 11) http://www.handandaily.com

发布日期 : 7/8/2005 | 更新日期 : 7/8/2005

Scott Mitchell
4GuysFromRolla.com

摘要：本文概述了 skmFAQs.NET，这是一个开放源代码的 ASP.NET .x 常见问题 (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，它为系统中的每个用户帐户提供了一个记录。每个用户帐户都由下列三个可能的选项之一赋予了特定的访问级别：

Administrator — 管理员可以创建或移除用户帐户和 FAQ 类别，以及创建、编辑或删除任何 FAQ。
Trusted Contributor — 具有张贴吸引人的、不含错误的 FAQ 的跟踪记录的投稿人被赋予受信任的投稿人访问权限。当受信任的投稿人创建新的 FAQ 时，它会立即出现在 Web 站点上。
Untrusted Contributor — 当新用户添加到该系统中时，他们将以该访问级别进入。不受信任的投稿人在没有得到 Administrator 批准之前，他们的新 FAQ 不会显示在站点中。这使我在采用它以前，有机会对其内容进行审阅和必要的修改。

我将我自己的用户帐户标记为唯一的管理员帐户，然后基于其他用户的以前跟踪记录，向他们分发受信任的投稿人和不受信任的投稿人状态。

尽管 ASPFAQs.com 多年来不断演变，但创建新 FAQ 仍然是一项相当深奥的操作，因为 ASPFAQs.com 的 Web 界面用特定标记（HTML 的子集）接受答案。这意味着投稿人必须学习这一标记，以便对他们的贴的格式设置具有更精细的控制。很多 Wiki 引擎用户也会遇到这一类似的问题。

回想起来，ASPFAQs.com 有很多非常棒的功能，但也有许多有待改进的地方。它的一些优点包括：

使多个投稿人能够轻松创建和编辑他们自己的 FAQ，而无需我进行任何干预。
提供不同级别的访问权限，尽管现在回想起来，这些访问级别划分得不够细（请参阅下一部分）。

主要的改进方面包括：

改进的数据输入体验。如果已经选择允许使用丰富文本编辑器（如 FreeTextBox）进行输入，而不是强迫投稿人记忆 ASPFAQs.com 语法，则会对用户更加友好一些。
对访问权限的更为精细的控制。我发现在 Administrator 和 Trusted Contributor 之间的某个位置需要有一个访问权限级别，从而使高度受信任的用户能够编辑或批准他人的 FAQ，但仍然不具有完整的管理权限。而且，ASPFAQs.com 访问权限对于所有 FAQ 类别而言是全局性的。理想情况下，可以按照类别向用户帐户分配访问权限。
投稿人无法相互补充对方的 FAQ。对于 ASPFAQs.com，投稿人只能编辑他们已经创建的 FAQ。如果投稿人 A 撰写了一个 FAQ，而投稿人 B 具有并且希望添加一份优秀的代码示例或说明，则她必须将她的补充内容用电子邮件发送给投稿人 A，然后，后者必须进入系统并追加该附录。
缺乏合理的体系结构。ASPFAQs.com 在创建时，其体系结构设计缺少远见。最终结果是，要扩展 ASPFAQs.com 不太容易。例如，添加新的 FAQ 类别要求手动操作 Web 界面；除了调用适当的存储过程以外，没有以编程方式创建它的 API。另外，要在另一个站点上或者在同一站点的另一部分上复制 ASPFAQs.com 中包含的任何种类的功能，都需要复制代码和数据库调用。
单层类别模型。尽管 ASPFAQs.com 可以支持任意数量的类别，但没有办法在它们之间建立层次结构。（例如，不可能创建一个带有诸如“Forms Authentication”、“Encryption”和“Authorization”之类子类别的“Security”类别。）

有了创建和维护 ASPFAQs.com 的实际经验，我对制定 skmFAQs.NET 的设计目标充满信心。

返回页首

skmFAQs.NET 的设计目标

在创建应用程序时，我通常会经历一个迭代的过程来制定设计目标。我首先制定少数几个非常高级的目标。在制定、权衡和接受这些目标以后，我就会将这些高级目标分解为更为具体的目标。该过程可能会经历多次迭代，直到我手头具有了一些非常具体的任务为止。

在创建 skmFAQs.NET 时，我决定使其可能满足下列三个高级目标：

易于使用；
提供各种级别的权限和权利，以便使成员按照类别发布 FAQ；以及
使应用程序具有高度的可扩展性和可自定义性。

有了上面列出的三个高级目标以后，下一步是将这些目标分解为更为具体的目标。

使 skmFAQs.NET 易于使用

我首先从“确保 skmFAQs.NET 易于使用”这一目标开始，并且写下了有关如何实现这一目标的想法。有两种不同类型的 skmFAQs.NET 用户：内容创建者和页开发人员。内容创建者是那些通过 Web 站点界面与应用程序交互的用户，他们向站点中添加新的 FAQ。另一方面，页开发人员是那些必须将 skmFAQs.NET 合并到现有 Web 应用程序中或者需要自定义 skmFAQs.NET 的功能或外观的用户。显然，对于上述两类用户而言，使 skmFAQs.NET 易于使用的目标大为不同。

经过一番苦思冥想，可以制定出这两类用户的具体目标，其中一些目标有助于另外两个高级目标的实现。通过 Web 界面添加 FAQ 的用户的目标包括：

添加 FAQ 应该像使用字处理器一样简单。不应该要求用户了解特殊的标记语言（甚至包括 HTML 在内）。
向现有的 FAQ 中追加内容应该是一项普通的任务，并且不需要原来的投稿人采取任何特殊操作。
管理任务 — 添加新用户、批准 FAQ、编辑/删除他人的 FAQ 等 — 应该简单而直接，并且全都可以通过 Web 界面完成。

上述一些比较具体的目标看起来可能是如此直观，以至于不值得将它们列出来。但是，我发现这样做有助于枚举那些甚至极为明显的目标和任务，部分原因在于它们可以帮助发现一些不这样做就可能得不到实现的功能。例如，进一步钻研上面列出的第二个目标，可以迫使我以批判的态度考虑哪些功能可以使向另一个人的 FAQ 中追加内容成为真正毫不费力的任务。另外，列出那些即使是显而易见的需求，可以提供一个完整的视野，而这又有助于确定时间估计、设置里程碑以及评价进度。

页开发人员的更为详细的目标包括：

能够通过编程 API 使用基于 Web 的功能。
在自定义 ASP.NET 服务器控件中封装常见用户界面功能。
简单而快速的安装和设置过程。

由于本文的目的是概述 skmFAQs.NET，而不是提供深入的功能性规范文档，因此我们就不再进一步探讨这些可用性目标了。当我们在本文的其余部分更详细地分析 skmFAQs.NET 的时候，您将了解有助于实现这些目标的功能和设计决策。

实现细粒度的访问权利

基于我从 ASPFAQs.com 中获得的经验，我希望在 skmFAQs.NET 中对访问权利提供更为精细的控制级别。在设计该系统时，我希望顾及一个用例，即大型站点可以使用单个 skmFAQs.NET 应用程序实例来设置多个独立的 FAQ 部分。

例如，请考虑一个与 Darren Neimke 的 Project Distributor 类似的站点。Project Distributor 是一个 Web 站点，它充当小型代码项目的储存库。用户可以在 Project Distributor 中创建帐户，并在那里宿主他们的应用程序。对于这样的 Web 应用程序，让每个用户具有对应于其软件项目的 FAQ 会很有用。每个用户的 FAQ 部分从任何可能的意义来说都与其他用户分隔：

用户 A 无法编辑用户 B 的 FAQ 部分，也无法向其添加 FAQ（除非被明确赋予相应的访问权利）。
在查看用户 A 的 FAQ 部分时，只会显示用户 A 的 FAQ，而不会显示用户 B、用户 C 等用户的 FAQ。

为了启用类似的方案，访问权利是按照类别实现的。要实现此类系统，需要为 Project Distributor 中的每个项目创建一个 FAQ 类别，并且使合适的用户收到所需的权利。（当使用 skmFAQs.NET API 在该系统中创建新用户帐户时，可以用编程方式完成该工作。）

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

创建 FAQ 条目。
编辑您自己的 FAQ 条目。
编辑所有 FAQ。
删除您自己的 FAQ。
删除他人的 FAQ。
批准或拒绝挂起的 FAQ。
将您自己的 FAQ 移至另一个类别。
将他人的 FAQ 移至另一个类别。
创建、编辑和删除子类别。

在一个极端的情况下，可以为每个类别的每个用户设置这些权限。一个不那么详细的方案会将相关权限组合到角色中，并且只允许按照用户、类别来分配角色。这两种极端的方案代表在表达性和可用性之间进行的经典折衷；因为我为 skmFAQs.NET 制定的主要设计目标之一是易于使用，所以我决定选择基于角色的方法。因此，该系统具有四个预定义的角色：

Administrator — 管理员角色是按照整个应用程序（而不是按照类别）应用的。标记为管理员的用户对所有类别中的所有 FAQ 具有完整的权利，并且可以创建、编辑和删除用户帐户。
FAQ Editor — FAQ 编辑类似于特定于类别的管理员。FAQ Editor 可以批准、创建、编辑和删除该类别内部的任何 FAQ。
Trusted Contributor — 与 ASPFAQs.com 一样，受信任的投稿人可以创建、编辑和删除他们自己的 FAQ，但不能对他人的 FAQ 执行操作。而且，当他们创建 FAQ 时，它会立即出现在站点中。
Untrusted Contributor — 也是与 ASPFAQs.com 一样，不受信任的投稿人可以创建、编辑和删除他们自己的 FAQ，但是当他们创建新的 FAQ 时，它必须首先由 FAQ Editor 或 Administrator 批准，然后才能出现在站点中。

图 1 显示 skmFAQs.NET“Permissions Administration”页的屏幕快照，只有管理员才能访问该页。在该屏幕中，管理员可以从下拉列表中选择用户，然后为该系统中的任何类别指定角色。

图 1. 权限管理

构建可扩展的且可自定义的应用程序

在三个高级设计目标中，重点是第三个也就是最后一个目标：确保 skmFAQs.NET 是可扩展的且可自定义的。在我过去使用预生成的商业 Web 应用程序的经历中，我已经忍受了大量挫折和痛苦，试图对相当呆板的应用程序进行调整以适合我的特定需求。为了提供能够满足不同客户的独特要求的应用程序，我将精力集中于下列两个目标：

提供简单明了的编程 API，以便提供与系统之间的强大接口，同时封装复杂性。
在数据访问层利用提供程序模型设计模式，从而使企业页开发人员可以交换出后端数据存储区，而无需进行任何其他更改。

skmFAQs.NET 的体系结构模仿了 Community Server 论坛（为 ASP.NET Forums 提供动力的论坛软件）所使用的体系结构，并且由下列四个层组成：

表示层，它包含应用程序的 ASP.NET 页，以及经过编译的自定义 ASP.NET 服务器控件（它们在 Web 控件中封装了常见功能）。
应用程序逻辑层，也称为 API，它包含一些用于以编程方式使用 FAQ 应用程序的类。
抽象数据访问层，它提供了与后端数据存储区交互的方法。数据访问层只是定义了 DAL 的方法和属性；要实际与后端数据存储区交互，需要有一个扩展并实际实现抽象 DAL 的提供程序类。skmFAQs.NET 附带了这样的一个利用 Microsoft SQL Server 2000 和更高版本的具体提供程序；开发人员可以生成他们自己的提供程序以插入到系统中，以便让 skmFAQs.NET 利用不同的后援存储区（如 Microsoft Access、XML 文件、Oracle 或其他存储区）。
数据存储区，它是数据库、XML 文件或其他存储区。

图 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。下载内容包括：

用于创建数据库的表、存储过程、视图、UDF 和初始数据的 SQL 脚本。
skmFAQs.NET 应用程序的完整 C# 源代码。
一个演示 Web 站点，可以原样使用，也可以进行定制以满足您的独特需要。

在下载 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 设置过程的详细信息，请参阅 http://skmfaqs.net/skmfaqs/ShowFAQ.aspx?ID=5。

返回页首

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 选项包括：

User Administration，除了允许按照类别分配权限以外，它还允许创建、编辑和删除用户帐户。
Category Administration，它用来创建、编辑和删除类别。
E-mail Template Administration，用来基于事件定制用户收到的电子邮件。例如，当 Untrusted Contributor 提交新的 FAQ 时，它必须首先由 Administrator 或 FAQ Editor 批准，然后才能出现在站点中。无论该 FAQ 被批准还是被拒绝，Contributor 都会收到详细说明采取了哪个操作的电子邮件。可以通过“E-mail Template Administration”页定制这一电子邮件类型和其他电子邮件类型的电子邮件内容。
Reports，它显示在给定的月份中，相应的 FAQ 或类别已被查看了多少次。“Reports”屏幕使用了由 Carlos Aguilar Mares 创建的免费 WebChart 控件。

FAQ Editor 和 Administrator 都可以使用的 FAQ Editor 选项包括：

FAQ Moderation，用来批准或拒绝来自 Untrusted Contributor 的挂起 FAQ 提交。
FAQ Maintenance，用来更新、删除或移动他人已经撰写的 FAQ。Administrator 可以更新或删除任何类别中的任何 FAQ。FAQ Editor 只能在他作为 FAQ Editor 的类别中更新或删除他人的 FAQ。

投稿人（包括受信任的和不受信任的）只能任意使用一个选项：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 的设计目标是既易于使用，又可以扩展。

祝大家编程愉快！

在将我的文章提交给 MSDN 编辑之前，我让一些志愿者帮助我校对该文章，并且提供有关该文章的内容、语法和说明的反馈。为本文的审阅过程做出贡献的主要人士包括：Atif Aziz¡¢Carl Lambrecht¡¢Julius Estrada、Jeffrey Palermo、Hilton Giesenow 和 Milan Negovan。如果您希望加入这个不断增长的审阅者列表，则请通过 mitchell@4guysfromrolla.com 与我联系。

相关书籍

关于作者

Scott Mitchell 已经撰写了六本书，并且创建了 4GuysFromRolla.com。在过去五年中，他一直在使用 Microsoft Web 技术。Scott 是一位独立的顾问、培训讲师和作家。您可以通过 mitchell@4guysfromrolla.com 或他的网络日记 http://ScottOnWriting.NET 与他联系。

http://msdn2.microsoft.com/zh-cn/library/ms972972.aspx

由于作者提供的下载站点已经失效，我添加上现在代码，我很早以前下载的,奉献出来吧！

我使用skmFAQs.NET构件的应用:http:/www.handandaily.com

转载于:https://www.cnblogs.com/kaixin110/archive/2007/12/21/1008687.html