一个方案描述主页如何列出最近添加到知识库中的内容，以供任何人查看。此例中的“用户”将是主页自身。还有一些方案描述专家如何查找和回复新问题以及管理员如何更新主题列表并管理系统的其他部分。我已为讨论这个简单的应用程序标识了 20 多种方案。您可以在 DotNetKB 中找到当前列表（以及与此项目相关的所有其他资料）。
至此我们就有了目标声明和一些用户方案。现在，是时候稍憩一下，然后学学一些技术了。我们需要定义应用程序体系结构，这可以帮助我们以“鲜活有效的代码”实际实现方案。
定义应用程序体系结构
有了基本的目的和为解决方案开发的用户方案列表后，您需要开始筹划整体的体系结构。主要目标是标识应用程序的逻辑方面和物理方面，即如何将应用程序拆分为各种有用的部分。在本节中还添加了安全性方面的内容。安全是在规划的“一开始”您就需要考虑的问题，而不是在开发周期中“最后添加”的内容。我们稍后会在本节中详细讨论这个问题。
逻辑体系结构
从逻辑上讲，您需要规划解决方案以标识数据存储、数据访问、业务规则、用户界面等之间的“边界”。通常，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、Internet Information Server、ASP.NET 和 .NET 运行时的单个实际计算机上实现这个应用程序。这将是一个物理层。但更可靠且可扩展的方法是：在由三个 Web 服务器组成的簇上部署 Web 窗体，在两个应用服务器上部署 .NET 组件程序集，在两个故障恢复模式的 SQL Server 上部署数据库。这样产生的物理体系结构将七个 Windows 服务器包含在三个主要组中：Web 簇、组件簇和数据库簇。如果您了解系统的不同逻辑部件可以位于不同的计算机上，您可能会实现不同的代码。
对于我们的示例，我们采用一个有效且强大的两层模型：Web 服务器托管用户界面和组件，数据库服务器托管 SQL Server 数据存储。如果通信量非常大，这个模型使我们可以灵活地在簇中添加更多的服务器，并使其保持足够的简洁以便于处理。下面的图像显示了此物理
