ASP.NET应用程序规划与设计

文档化用户方案

　　用户方案没有什么令人惊异之处。通常，它们只是描述用户如何与应用程序交互。用户方案的关键价值在于记录了关于每个人对用户希望系统如何运行以及应用程序应如何响应的设想。通过完成这个过程，您将可以完全了解处理各种用户与系统的交互时所需的数据点和函数。换句话说，编写完善的用户方案将有助于您确定完成解决方案需要实现的数据库、中间件和用户界面元素。

　　注意：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 安全等）。同样，我们稍后会在本节中详细讨论这个问题。