当前页面位置: » 丰搜网 » 文档中心 » 详细内容
asp.net应用程序规划与设计(1)
简介
这是一个系列文章，在这个系列文章中我们将逐步详细介绍如何使用 microsoft asp.net 和 microsoft visual studio.net 来设计、实现和部署典型的 web 应用程序，以探讨实际应用程序创建实践中最常见的几个因素。 我们不仅仅布置一些 web 窗体，也不局限于只对后端数据库进行一些数据绑定。数据绑定和 web 窗体布局很重要，但是有许多其他问题也非常重要。
例如，无论采用何种目标平台或语言，所有经过良好编码的项目都包括一些基本的规划步骤，例如目标声明、用户方案文档，甚至用于标识解决方案的物理边界和逻辑边界的体系结构文档。此外，在解决方案生命周期的早期就将安全规划包含在内是一种非常好的习惯。这些内容与良好的数据库模型、精心设计的中间件组件以及简洁的用户界面设计一起，可以确保您最终在生产中部署的应用程序是安全的、可靠的，并且是用户友好的。
此时，一些读者可能会认为本文属于那些基调很高的文章，目标定位在某些超大型企业级方案，而这种方案根本不适用于一般的小工厂、爱好者或个人开发团体。其实并不是这样！即使只是创建您自己个人使用的基于 web 的小型解决方案，从一开始就进行完善的规划将有助于确保流程最终的轻松实现和部署。而且，并不是高级的程序员或 web 开发人员才可以使用这些技术。无论您的技术水平如何，也无论您属于哪类目标读者，我相信您都会发现这一系列文章对您很有帮助，它为您提供了丰富的信息，而且（请允许我这样说）十分有趣。
我们将生成一个称为 do.netkb 的示例知识库 web 应用程序，这个过程将贯穿整个系列文章。在作为第一篇文章的本文中，我们将介绍典型项目的设计阶段，包括基本规划、应用程序体系结构和实现方案设计。学习完本文后，您将已经准备好所有的文档，并会迫不及待地希望开始创建解决方案。
预备工作非常简单，我们跳过这部分内容，直接开始第一步“应用程序规划”。
规划基本 asp.net 应用程序
使用 visual studio .net 创建基于 web 的 asp.net 应用程序的第一步是制定基本的应用程序规划 (ap)。制定规划不仅对于由多个开发人员建立的大型解决方案而言是必不可少的，而且即使对于最小的应用程序，一个完善的 ap 也是非常重要的。创建 ap 有助于您在开始编码“之前”就能仔细考虑一些常见问题。这样，您可以在应用程序生命周期的早期便完全了解挑战和解决方案，而不是在完全陷入窘境之后才发现问题。在《software project survival guide》一书中，作者 steve mcconnell 指出：在软件项目后期纠正错误所花的成本与在早期阶段发现并纠正这些错误所花的成本相比，前者可能是后者的 50 - 200 倍。
一个完善的项目规划包含哪些内容？可以包含许多内容，但最基本的是要包含目标声明和一系列用户方案。还有其他很多有用的资料，包括需求文档、编码标准、交付进度、测试过程等。对于我们要建立的简单示例解决方案，将主要介绍简单的应用程序声明和一些用户方案。同时还将解决一些其他问题。
应用程序声明
此系列文章要建立的项目（称为 do.netkb）是一个简单的知识库 web 站点，在这个站点中，用户可以提各种问题，并可以得到授权“专家”的回答。这样，以后访问者在查找常见 asp.net 问题的解决方案时，可以对得到的结果数据进行搜索和过滤。
这是对我们的 do.netkb 项目的一个基本目标声明。do.netkb 是一个基于 web 的应用程序，它可以列出访问者提出的一系列问题，并显示授权专家对这些问题作出的回复。访问者可以向系统添加新问题，并可以按照问题的主题、问题和/或回答中的关键字来搜索和过滤这些问题。访问者还可以按主题或按添加到系统中的日期来对问题列表进行排序。
授权专家可以登录到应用程序中已设置安全机制的部分，审阅问题，添加、编辑和删除对一个问题的一个或多个回答。应用程序管理员还可以建立专家登录权限和登录配置文件，以及添加、编辑和删除问题主题。
此外，还提供了一些基本统计信息，包括系统中问题和回答的数量，以及每个专家的回复数量和至今已被访问的页面数量。
正如您从上面的声明中看到的那样，该解决方案非常简单。在阅读目标声明时，您可能会开始考虑可以添加到这个应用程序的许多其他功能，以使应用程序更加强大。这说明了项目目标声明的一个主要依据，即避免“功能蔓延”。我们都清楚，如果更改最终结果本来基于的概念，简单的想法将导致非常庞大且歪曲的结果。有句老格言：“如果不知道要去往何方，你可能会在某个地方停下来”，它原本揭示的是夏季公路旅行，其道理同样可用于软件项目。
一些项目的目标声明中可能需要包含更多的信息。而对于我们的使用，上面的目标声明就符合要求。现在我们对于要完成的应用程序有了一个清晰的认识，接下来需要一些详细的信息来描述用户如何与系统交互以及用户需要执行哪些任务来完成目标。我们需要一系列用户方案。
文档化用户方案
用户方案没有什么令人惊异之处。通常，它们只是描述用户如何与应用程序交互。用户方案的关键价值在于记录了关于每个人对用户希望系统如何运行以及应用程序应如何响应的设想。通过完成这个过程，您将可以完全了解处理各种用户与系统的交互时所需的数据点和函数。换句话说，编写完善的用户方案将有助于您确定完成解决方案需要实现的数据库、中间件和用户界面元素。
注意：visual studio .net enterprise architect 有一项非常不错的功能，即允许您使用 microsoft visio? 通过 uml（统一建模语言）创建用户方案，然后生成这些方案的基本代码。在这里，我不打算深入探讨这些细节，但是您可以在 msdn? academic alliance 站点找到一篇关于这一主题的好文章 generating .net code using visio enterprise architect's uml，作者是 sreedhar koganti。
有了上一节的目标声明后，下面是 do.netkb 项目的几个示例用户方案。
搜索知识库
匿名用户可以输入一个或多个关键字并执行搜索，搜索将返回包含这些关键字的问题和/或回答列表。用户可以将关键字搜索锁定在仅搜索问题、仅搜索回答或者二者都搜索。返回的列表将显示问题及其回复数和被其他用户访问的次数。单击链接将返回以时间先后逆序排列的回复（纯文本）列表。
将新问题输入到知识库中
匿名用户可以浏览用于向数据库输入新问题以供授权专家审阅和回复的屏幕。用户可以输入问题的标题和内容，并可以选择在一系列主题中的某个主题下记录该问题。用户还可以输入他们的名字和相关的 url（电子邮件、web 地址等）。输入将被验证，以确保包含必需的数据并确保所有输入数据不会受到脚本攻击等。一旦数据经过验证并被保存到数据库中，用户将看到一个响应屏幕，感谢用户的支持并将用户直接连接到主页。此外，用户还可以选择让该站点“记住”他们的姓名和 url 以备以后访问该站点时使用。
您已经了解它的工作原理了，对吗？每一个方案都尝试细化用户交互的重要方面。例如，上面列出的两个方案表明用户为“anonymous”（匿名用户），这表示这类用户不需要登录或进行其他方式的授权。第二个示例还标识了若干输入值、验证步骤和可选操作。
当然，这只是两个示例；完整的系统需要更多的方案。此外，需要特别注意的是，“用户”不仅仅可以是人，也可以是您的程序需要与其通信的其他应用程序，甚至还可以是您的应用程序的其他部分。例如，一个方案描述主页如何列出最近添加到知识库中的内容，以供任何人查看。此例中的“用户”将是主页自身。还有一些方案描述专家如何查找和回复新问题以及管理员如何更新主题列表并管理系统的其他部分。我已为讨论这个简单的应用程序标识了 20 多种方案。您可以在 do.netkb 中找到当前列表（以及与此项目相关的所有其他资料）。
至此我们就有了目标声明和一些用户方案。现在，是时候稍憩一下，然后学学一些技术了。我们需要定义应用程序体系结构，这可以帮助我们以“鲜活有效的代码”实际实现方案。
定义应用程序体系结构
有了基本的目的和为解决方案开发的用户方案列表后，您需要开始筹划整体的体系结构。主要目标是标识应用程序的逻辑方面和物理方面，即如何将应用程序拆分为各种有用的部分。在本节中还添加了安全性方面的内容。安全是在规划的“一开始”您就需要考虑的问题，而不是在开发周期中“最后添加”的内容。我们稍后会在本节中详细讨论这个问题。
逻辑体系结构
从逻辑上讲，您需要规划解决方案以标识数据存储、数据访问、业务规则、用户界面等之间的“边界”。通常，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、inte.net information server、asp.net 和 .net 运行时的单个实际计算机上实现这个应用程序。这将是一个物理层。但更可靠且可扩展的方法是：在由三个 web 服务器组成的簇上部署 web 窗体，在两个应用服务器上部署 .net 组件程序集，在两个故障恢复模式的 sql server 上部署数据库。这样产生的物理体系结构将七个 windows 服务器包含在三个主要组中：web 簇、组件簇和数据库簇。如果您了解系统的不同逻辑部件可以位于不同的计算机上，您可能会实现不同的代码。
对于我们的示例，我们采用一个有效且强大的两层模型：web 服务器托管用户界面和组件，数据库服务器托管 sql server 数据存储。如果通信量非常大，这个模型使我们可以灵活地在簇中添加更多的服务器，并使其保持足够的简洁以便于处理。下面的图像显示了此物理体系结构与前面定义的逻辑体系结构之间的映射关系。
图 2：物理体系结构与三层体系结构之间的映射关系
正如您看到的那样，逻辑体系结构和物理体系结构不必相同。在规划阶段还要考虑一项内容：安全。
