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