欢迎进入.NET社区论坛，与200万技术人员互动交流 >>进入 通过上一篇文章《规划基本 ASP.NET
应用程序》的学习，有了基本的目的和为解决方案开发的用户方案列表后，您需要开始筹划整体的体系结构。主要目标是标识应用程序的逻辑方面和物理方面，即如何将应用程序拆分为各种有用的部分。在本节中还添加了安全
性方面的内容。安全是在规划的“一开始”您就需要考虑的问题，而不是在开发周期中“最后添加”的内容。我们稍后会在本节中详细讨论这个问题。
逻辑体系结构
从逻辑上讲，您需要规划解决方案以标识数据存储、数据访问、业务规则、用户界面等之间的“边界”。通常，Web 开发人员会选择一个两阶段模型，并用 Web 窗体存储用于访问现有数据存储系统(例如 Microsoft SQL Server)的所有代码。一个更有效的方法是创建一个位于 Web 窗体用户界面与 SQL Server 数据存储系统之间的中间层组件库。这种三层方法(Web 窗体、组件、数据库)通常是大多数应用程序所需的。但是，在某些情况下，可能需要一个其他层来处理服务器之间传输的数据。这个传输层可以使用独立于平台的协议(例如 XML-SOAP)来实现。但是，如果您从头到尾都使用 Microsoft .NET 技术，则可以使用 .NET 远程协议的二进制版来完成这一任务，而且速度比使用 XML-SOAP 要快得多。
对于我们的示例，我们将定义三个逻辑边界：用户界面(Web 窗体)、中间层(一个 .NET 组件程序集)和数据层(SQL Server 数据库)。图 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：物理体系结构与三层体系结构之间的映射关系
