摘要：了解如何规划和设计 ASP.NET 应用程序。本文以一个知识库 Web 应用程序为例，讨论实际应用程序创建实践中最常见的几个因素。
简介
这是一个系列文章，在这个系列文章中我们将逐步详细介绍如何使用 Microsoft ASP.NET 和 Microsoft Visual Studio.NET 来设计、实现和部署典型的 Web 应用程序，以探讨实际应用程序创建实践中最常见的几个因素。我们不仅仅布置一些 Web 窗体，也不局限于只对后端数据库进行一些数据绑定。数据绑定和 Web 窗体布局很重要，但是有许多其他问题也非常重要。
例如，无论采用何种目标平台或语言，所有经过良好编码的项目都包括一些基本的规划步骤，例如目标声明、用户方案文档，甚至用于标识解决方案的物理边界和逻辑边界的体系结构文档。此外，在解决方案生命周期的早期就将安全规划包含在内是一种非常好的习惯。这些内容与良好的数据库模型、精心设计的中间件组件以及简洁的用户界面设计一起，可以确保您最终在生产中部署的应用程序是安全的、可靠的，并且是用户友好的。
此时，一些读者可能会认为本文属于那些基调很高的文章，目标定位在某些超大型企业级方案，而这种方案根本不适用于一般的小工厂、爱好者或个人开发团体。其实并不是这样！即使只是创建您自己个人使用的基于 Web 的小型解决方案，从一开始就进行完善的规划将有助于确保流程最终的轻松实现和部署。而且，并不是高级的程序员或 Web 开发人员才可以使用这些技术。无论您的技术水平如何，也无论您属于哪类目标读者，我相信您都会发现这一系列文章对您很有帮助，它为您提供了丰富的信息，而且（请允许我这样说）十分有趣。
我们将生成一个称为 DotNetKB 的示例知识库 Web 应用程序，这个过程将贯穿整个系列文章。在作为第一篇文章的本文中，我们将介绍典型项目的设计阶段，包括基本规划、应用程序体系结构和实现方案设计。学习完本文后，您将已经准备好所有的文档，并会迫不及待地希望开始创建解决方案。
预备工作非常简单，我们跳过这部分内容，直接开始第一步“应用程序规划”。
规划基本 ASP.NET 应用程序
使用 Visual Studio .NET 创建基于 Web 的 ASP.NET 应用程序的第一步是制定基本的应用程序规划 (AP)。制定规划不仅对于由多个开发人员建立的大型解决方案而言是必不可少的，而且即使对于最小的应用程序，一个完善的 AP 也是非常重要的。创建 AP 有助于您在开始编码“之前”就能仔细考虑一些常见问题。这样，您可以在应用程序生命周期的早期便完全了解挑战和解决方案，而不是在完全陷入窘境之后才发现问题。在《Software Project Survival Guide》一书中，作者 Steve McConnell 指出：在软件项目后期纠正错误所花的成本与在早期阶段发现并纠正这些错误所花的成本相比，前者可能是后者的 50 - 200 倍。
一个完善的项目规划包含哪些内容？可以包含许多内容，但最基本的是要包含目标声明和一系列用户方案。还有其他很多有用的资料，包括需求文档、编码标准、交付进度、测试过程等。对于我们要建立的简单示例解决方案，将主要介绍简单的应用程序声明和一些用户方案。同时还将解决一些其他问题。
应用程序声明
此系列文章要建立的项目（称为 DotNetKB）是一个简单的知识库 Web 站点，在这个站点中，用户可以提各种问题，并可以得到授权“专家”的回答。这样，以后访问者在查找常见 ASP.NET 问题的解决方案时，可以对得到的结果数据进行搜索和过滤。
这是对我们的 DotNetKB 项目的一个基本目标声明。DotNetKB 是一个基于 Web 的应用程序，它可以列出访问者提出的一系列问题，并显示授权专家对这些问题作出的回复。访问者可以向系统添加新问题，并可以按照问题的主题、问题和/或回答中的关键字来搜索和过滤这些问题。访问者还可以按主题或按添加到系统中的日期来对问题列表进行排序。
授权专家可以登录到应用程序中已设置安全机制的部分，审阅问题，添加、编辑和删除对一个问题的一个或多个回答。应用程序管理员还可以建立专家登录权限和登录配置文件，以及添加、编辑和删除问题主题。
此外，还提供了一些基本统计信息，包括系统中问题和回答的数量，以及每个专家的回复数量和至今已被访问的页面数量。
正如您从上面的声明中看到的那样，该解决方案非常简单。在阅读目标声明时，您可能会开始考虑可以添加到这个应用程序的许多其他功能，以使应用程序更加强大。这说明了项目目标声明的一个主要依据，即避免“功能蔓延”。我们都清楚，如果更改最终结果本来基于的概念，简单的想法将导致非常庞大且歪曲的结果。有句老格言：“如果不知道要去往何方，你可能会在某个地方停下来”，它原本揭示的是夏季公路旅行，其道理同样可用于软件项目。
一些项目的目标声明中可能需要包含更多的信息。而对于我们的使用，上面的目标声明就符合要求。现在我们对于要完成的应用程序有了一个清晰的认识，接下来需要一些详细的信息来描述用户如何与系统交互以及用户需要执行哪些任务来完成目标。我们需要一系列用户方案。
文档化用户方案
用户方案没有什么令人惊异之处。通常，它们只是描述用户如何与应用程序交互。用户方案的关键价值在于记录了关于每个人对用户希望系统如何运行以及应用程序应如何响应的设想。通过完成这个过程，您将可以完全了解处理各种用户与系统的交互时所需的数据点和函数。换句话说，编写完善的用户方案将有助于您确定完成解决方案需要实现的数据库、中间件和用户界面元素。
注意：Visual Studio .NET Enterprise Architect 有一项非常不错的功能，即允许您使用 Microsoft Visio? 通过 UML（统一建模语言）创建用户方案，然后生成这些方案的基本代码。在这里，我不打算深入探讨这些细节，但是您可以在 MSDN? Academic Alliance 站点找到一篇关于这一主题的好文章 Generating .NET Code Using Visio Enterprise Architect's UML，作者是 Sreedhar Koganti。
有了上一节的目标声明后，下面是 DotNetKB 项目的几个示例用户方案。
搜索知识库
匿名用户可以输入一个或多个关键字并执行搜索，搜索将返回包含这些关键字的问题和/或回答列表。用户可以将关键字搜索锁定在仅搜索问题、仅搜索回答或者二者都搜索。返回的列表将显示问题及其回复数和被其他用户访问的次数。单击链接将返回以时间先后逆序排列的回复（纯文本）列表。
将新问题输入到知识库中
匿名用户可以浏览用于向数据库输入新问题以供授权专家审阅和回复的屏幕。用户可以输入问题的标题和内容，并可以选择在一系列主题中的某个主题下记录该问题。用户还可以输入他们的名字和相关的 URL（电子邮件、Web 地址等）。输入将被验证，以确保包含必需的数据并确保所有输入数据不会受到脚本攻击等。一旦数据经过验证并被保存到数据库中，用户将看到一个响应屏幕，感谢用户的支持并将用户直接连接到主页。此外，用户还可以选择让该站点“记住”他们的姓名和 URL 以备以后访问该站点时使用。
您已经了解它的工作原理了，对吗？每一个方案都尝试细化用户交互的重要方面。例如，上面列出的两个方案表明用户为“anonymous”（匿名用户），这表示这类用户不需要登录或进行其他方式的授权。第二个示例还标识了若干输入值、验证步骤和可选操作。
当然，这只是两个示例；完整的系统需要更多的方案。此外，需要特别注意的是，“用户”不仅仅可以是人，也可以是您的程序需要与其通信的其他应用程序，甚至还可以是您的应用程序的其他部分。例如，一个方案描述主页如何列出最近添加到知识库中的内容，以供任何人查看。此例中的“用户”将是主页自身。还有一些方案描述专家如何查找和回复新问题以及管理员如何更新主题列表并管理系统的其他部分。我已为讨论这个简单的应用程序标识了 20 多种方案。您可以在 DotNetKB 中找到当前列表（以及与此项目相关的所有其他资料）。
至此我们就有了目标声明和一些用户方案。现在，是时候稍憩一下，然后学学一些技术了。我们需要定义应用程序体系结构，这可以帮助我们以“鲜活有效的代码”实际实现方案。
定义应用程序体系结构
有了基本的目的和为解决方案开发的用户方案列表后，您需要开始筹划整体的体系结构。主要目标是标识应用程序的逻辑方面和物理方面，即如何将应用程序拆分为各种有用的部分。在本节中还添加了安全性方面的内容。安全是在规划的“一开始”您就需要考虑的问题，而不是在开发周期中“最后添加”的内容。我们稍后会在本节中详细讨论这个问题。
逻辑体系结构
从逻辑上讲，您需要规划解决方案以标识数据存储、数据访问、业务规则、用户界面等之间的“边界”。通常，Web 开发人员会选择一个两阶段模型，并用 Web 窗体存储用于访问现有数据存储系统（例如 Microsoft SQL Server）的所有代码。一个更有效的方法是创建一个位于 Web 窗体用户界面与 SQL Server 数据存储系统之间的中间层组件库。这种三层方法（Web 窗体、组件、数据库）通常是大多数应用程序所需的。但是，在某些情况下，可能需要一个其他层来处理服务器之间传输的数据。这个传输层可以使用独立于平台的协议（例如 XML-SOAP）来实现。但是，如果您从头到尾都使用 Microsoft .NET 技术，则可以使用 .NET 远程协议的二进制版来完成这一任务，而且速度比使用 XML-SOAP 要快得多。
对于我们的示例，我们将定义三个逻辑边界：用户界面（Web 窗体）、中间层（一个 .NET 组件程序集）和数据层（SQL Server 数据库）。图 1 显示了如何表示这一内容。
图 1：三层图
现在我们有一个简单的逻辑模型。它是如何起作用的？它有助于我们考虑各个逻辑组之间的边界。每个逻辑层应尽量与其他层独立。理想的情况是，图层中的更改应该对整体产生最小的影响。例如，如果将数据存储从 SQL Server 更改到 XML 数据文件，唯一受到影响的图层应是中间层图层。用户界面应该根本无需考虑更改。这会使您进行思考：如何实现解决方案的实际编码以实现此原则。
另外，逻辑层有助于我们考虑安全问题。各个图层之间的边界都存在潜在的安全漏洞。而且，各个图层可能有自己特定的安全措施（SQL Server 权限、.NET 运行时权限、ASP.NET 安全等）。同样，我们稍后会在本节中详细讨论这个问题。
物理体系结构
确定逻辑层后，考虑物理层也很重要。例如，您可以在同时安装有 SQL Server、Internet Information Server、ASP.NET 和 .NET 运行时的单个实际计算机上实现这个应用程序。这将是一个物理层。但更可靠且可扩展的方法是：在由三个 Web 服务器组成的簇上部署 Web 窗体，在两个应用服务器上部署 .NET 组件程序集，在两个故障恢复模式的 SQL Server 上部署数据库。这样产生的物理体系结构将七个 Windows 服务器包含在三个主要组中：Web 簇、组件簇和数据库簇。如果您了解系统的不同逻辑部件可以位于不同的计算机上，您可能会实现不同的代码。
对于我们的示例，我们采用一个有效且强大的两层模型：Web 服务器托管用户界面和组件，数据库服务器托管 SQL Server 数据存储。如果通信量非常大，这个模型使我们可以灵活地在簇中添加更多的服务器，并使其保持足够的简洁以便于处理。下面的图像显示了此物理体系结构与前面定义的逻辑体系结构之间的映射关系。
图 2：物理体系结构与三层体系结构之间的映射关系
正如您看到的那样，逻辑体系结构和物理体系结构不必相同。在规划阶段还要考虑一项内容：安全。
安全规划
Microsoft 有一个关于安全性与软件这一主题的歌诀：“Secure by design, secure by default, and secure by deployment（设计安全，默认安全和部署安全）”。即，在安全中设计，期待系统在默认情况下是安全的，以及创建可以在安全环境中成功部署的解决方案。安全始终是重要的。既然越来越多的软件要在公用的 Internet 上“生存”，编写安全的软件就更加关键。对于我们而言，幸运的是，.NET 运行时和 Windows 操作系统提供广泛的安全选项和功能，我们可以轻松地将其包含在我们的应用程序中。无需过分注重标识和消除联机解决方案中安全漏洞的细节，我们可以指出其中一些最常见的漏洞并指出我们的应用程序规划如何进行处理。
注意：有关可用选项的详细信息，请参阅 Microsoft Security Developer Center。
缓冲区溢出
这可能是已编译应用程序中最常见的安全漏洞。由于我们将使用 .NET 运行时，而它是设计用来在内存中安全运行的，因此不太可能发生缓冲区溢出。此外，我们使用 Microsoft Visual Basic? .NET 对解决方案进行编码，而 Microsoft Visual Basic? .NET 不像 C 或 C++ 那样容易受到缓冲区溢出问题的影响。但是，即使我们打算用 C++ 创建组件，我们还可以使用编译程序的特殊功能，GS 转换，来保护我们免受大多数缓冲区溢出的攻击。
数据库攻击
另一种常见的安全漏洞可能会使恶意用户获得访问存储在数据库中的原始数据的权限。为了防止黑客获得数据的控制权，我们仅使用 SQL Server 存储过程，而不使用“内联查询”。这样可以大大减少试图在输入流中插入其他 SQL 命令的攻击。我们还在程序中多个位置处使用输入验证，以确保所有输入仅包含有效的字符。
交叉站点脚本攻击
对 Web 应用程序进行的常见攻击还有一种，它涉及到用户在输入流中添加客户方脚本，这类攻击将执行附加的对话并诱骗用户将个人数据发送到黑客自己的 Web 站点。要解决这个问题，我们使用 ASP.NET 1.1 的一个新功能，过滤出这种恶意代码的所有输入，防止将它置入系统中。显示屏幕上还包含附加代码，它将自动禁用任何脚本或显示可能会插入到数据存储中的标记。
至此，我们已获得了应用程序的逻辑模型和物理模型，以及确保实现方案包含的安全功能清单。拥有了这些以及目标声明和用户方案，我们可以开始这次“编码前”探险的最后一部分了。
完成设计文档
在直接进入项目的编码部分之前，需要花一点时间实际勾画出应用程序的逻辑组件，这非常重要。在我们的示例解决方案中，我们要实现解决方案的三个逻辑组件：数据库、.NET 数据访问组件和 ASP.NET 用户界面。在下面几篇文章中，我们将非常详细地介绍如何实现这些组件。但现在，我们只是勾画出每个组件的大致轮廓，讨论过程中最重要的方面，即文档化组件间的交互。
数据库
对于 DotNetKB 应用程序，我们需要将数据存储在三张表中：主题、问题和回答（请参阅下图）。
图 3：主题、问题和回答表
我们需要使用存储过程，以使中间层组件也可以安全地访问数据。有关数据库的细节，我们将在下一篇文章中讨论。这里，我们只是指出：列出表名称及所有列细节、默认索引和存储过程列表的数据库文档，应该包含在一个完整的数据库设计文档中。即，文档中应该具有成功实现系统数据存储部分所需的详细信息。
注意：如果留心的话，您可能会注意到我们未提及将专家数据存储在数据库中。只是为了使项目更加有趣（同时给我们一个机会使用直接 XML 数据存储），我们将专家信息存储在一个 XML 数据文件中。
数据访问组件
数据访问组件设计文档描绘与数据存储系统的交互以及与用户界面的交互的所有细节。在有些系统中，数据访问组件实际上是处理过程中各种问题的多个程序集。例如，可能会有一系列业务规则呈现在与数据存储和检索完全独立的用户界面上。在这种情况下，将业务组件与数据访问组件分开实现可能比较明智。
在我们的示例中，实际实现的是两个单独的组件：Message 组件和 DataAccess 组件。如果在支持基于 XML 的数据的传输服务（例如 SOAP Web Service）中进行规划，这种面向消息的实现方案将会特别有成效。
消息组件
消息组件定义一系列用于在各图层之间传输数据的类。这些消息可以作为二进制或 XML 文本数据存在。消息图层的价值在于：保护系统的其余部分，使其独立于数据存储实现方案的具体细节，例如 SQL Server、XML 文件等。此外，通过实现消息图层而不是更复杂的“智能对象”库，我们的解决方案可以更轻松地支持那些不能同时发送数据和类级别逻辑的远程调用服务，例如 XML-SOAP。
下面是一个消息类示例，在该示例中实现了 Topic 消息及其集合：
Public Class Topic
Private _ID As Integer
Private _Title As String
Private _Description As String
Public Property ID() As Integer
Get
Return _ID
