有了基本的目的和为解决方案开发的用户方案列表后，您需要开始筹划整体的体系结构。主要目标是标识应用程序的逻辑方面和物理方面，即如何将应用程序拆分为各种有用的部分。在本节中还添加了安全性方面的内容。安全是在规划的“一开始”您就需要考虑的问题，而不是在开发周期中“最后添加”的内容。我们稍后会在本节中详细讨论这个问题。

　　从逻辑上讲，您需要规划解决方案以标识数据存储、数据访问、业务规则、用户界面等之间的“边界”。通常，Web 开发人员会选择一个两阶段模型，并用 Web 窗体存储用于访问现有数据存储系统(例如 Microsoft SQL Server)的所有代码。一个更有效的方法是创建一个位于 Web 窗体用户界面与 SQL Server 数据存储系统之间的中间层组件库。这种三层方法(Web 窗体、组件、数据库)通常是大多数应用程序所需的。但是，在某些情况下，可能需要一个其他层来处理服务器之间传输的数据。这个传输层可以使用独立于平台的协议(例如 XML-SOAP)来实现。但是，如果您从头到尾都使用 Microsoft .NET 技术，则可以使用 .NET 远程协议的二进制版来完成这一任务，而且速度比使用 XML-SOAP 要快得多。

　　对于我们的示例，我们将定义三个逻辑边界：用户界面(Web 窗体)、中间层(一个 .NET 组件程序集)和数据层(SQL Server 数据库)。

　　现在我们有一个简单的逻辑模型。它是如何起作用的?它有助于我们考虑各个逻辑组之间的边界。每个逻辑层应尽量与其他层独立。理想的情况是，图层中的更改应该对整体产生最小的影响。例如，如果将数据存储从 SQL Server 更改到 XML 数据文件，唯一受到影响的图层应是中间层图层。用户界面应该根本无需考虑更改。这会使您进行思考：如何实现解决方案的实际编码以实现此原则。

　　另外，逻辑层有助于我们考虑安全问题。各个图层之间的边界都存在潜在的安全漏洞。而且，各个图层可能有自己特定的安全措施(SQL Server 权限、.NET 运行时权限、ASP.NET 安全等)。同样，我们稍后会在本节中详细讨论这个问题。

　　物理体系结构

　　确定逻辑层后，考虑物理层也很重要。例如，您可以在同时安装有 SQL Server、Internet Information Server、ASP.NET 和 .NET 运行时的单个实际计算机上实现这个应用程序。这将是一个物理层。但更