物理体系结构 确定逻辑层后，考虑物理层也很重要。例如，您可以在同时安装有 SQL Server、Internet Information Server、ASP.NET 和 .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 站点。要解决这个问题，我们使用 ASP.NET 1.1 的一个新功能，过滤出这种恶意代码的所有输入，防止将它置入系统中。显示屏幕上还包含附加代码，它将自动禁用任何脚本或显示可能会插入到数据存储中的标记。      　　至此，我们已获得了应用程序的逻辑模型和物理模型，以及确保实现方案包含的安全功能清单。拥有了这些以及目标声明和用户方案，我们可以开始这次“编码前”探险的最后一部分了。      　　完成设计文档      　　在直接进入项目的编码部分之前，需要花一点时间实际勾画出应用程序的逻辑组件，这非常重要。在我们的示例解决方案中，我们要实现解决方案的三个逻辑组件：数据库、.NET 数据访问组件和 ASP.NET 用户界面。在下面几篇文章中，我们将非常详细地介绍如何实现这些组件。但现在，我们只是勾画出每个组件的大致轮廓，讨论过程中最重要的方面，即文档化组件间的交互。      　　数据库      　　对于 DotNetKB 应用程序，我们需要将数据存储在三张表中：主题、问题和回答（请参阅下图）。