摘要：讨论 Microsoft .net 的应用程序设计和所需的更改：检验从使用 Microsoft Windows DNA 构建 N 层应用程序中学到的结构知识，以及如何将这些知识应用到使用 Microsoft .NET 框架构建的应用程序，并且为使用 XML Web Services 的应用程序提供体系结构方面的建议。

　　简介

　　如今，N 层应用程序已经成为构建企业软件的标准。对于大多数人来说，N 层应用程序就是被分成多个独立的逻辑部分的应用程序。最常见的选择是分为三个部分：表示、业务逻辑和数据，当然还可能存在其他的划分方法。N 层应用程序最初是为了解决与传统的客户端/服务器应用程序相关的问题而出现的，但是，随着 Web 时代的到来，这一体系结构开始成为新开发项目的主流。

　　Microsoft Windows? DNA 技术已成为 N 层应用程序的非常成功的基础。Microsoft .NET 框架也为构建 N 层应用程序提供了坚实的平台。然而，。NET 所带来的变化使结构设计人员应当重新考虑他们在 Windows DNA 领域中所学的有关设计 N 层应用程序的某些知识。更重要的是，对内置于 .NET 框架的 XML Web services 的基本支持允许开发人员构建突破传统 N 层方法的新应用程序。要了解如何更好地构建 .NET 应用程序的体系结构，您需要了解这一新领域中发生了哪些变化，以及如何充分利用这些变化。

　　本文将对这些问题进行讨论。首先回顾一下在使用 Windows DNA 构建 N 层应用程序中学到的关键体系结构知识。然后，再按同一顺序将这些知识应用到使用 .NET 框架构建应用程序的过程中，从而对它们进行检验。最后一部分对使用 XML Web services 的应用程序的体系结构提供了一些建议。

　　Windows DNA 环境

　　将应用程序恐解成多个逻辑部分是很有铀的。将一个大软件分成几个小的部分会更利于软件的构建、重复利用和修改，对适应不同的技术或不同典业务组织也很有帮助。同时，还有一些综合因素需要考虑。虽然模块化和重复使用性很有效，但它们可能会导致赢用程序不能象使用其他方法那样安全、易管理和快速。本节将回顾一些从使用 Windows DNA牸际豕菇?N 层应用程序的普遍经验中所获得的基1咎逑到峁怪丁?

　　编写业务逻辑

　　Windows DNA 应用程序通常使用以下三种实现方式中的一种或多种方式来实现其业务逻辑：

　　●ASP 页

　　●COM 组峻，可能使用 COM+ 提供的其他服务

　　●在 DBMS 中运行的存储过程

　　一般来讲，在 ASP 页中编写过多的业务逻辑并不是一个好办法。因为必须使用简单的语言，例如 Microsoft Visual Basic? Script (VBScript)，而且每次执行时都要解释代码，这会对性能造成影响。而且 ASP 页中的代码不好维护，主要是因为业务逻辑通常与创建用户界面的表示代码混合在一起。

　　鉴于这种情况，建议在编写中间层业务逻辑时，将业务逻辑当作 COM 对象来实现。这种方法比编写纯粹的 ASP 应用程序要稍微复杂一点，但是可以使用全功能语言来生成编译好的可执行文件，因此其结果要快得多。将业务逻辑包装在 COM 对象中还可以将此代码与包含在 ASP 页中的表示代码完全分隔开来，从而使应用程序更易于维护。

　　从 COM 到 COM+，其体系结构相差无几。但是，正如许多 Windows DNA 体系结构设计人员所了解的，除非真正需要，否则不应使用 COM+ 提供的核心服务，如事务、实时 (JIT) 激活、基于角色的安全性和线程服务等。使用其他开发平台提供的 COM+ 或类似服务自然会导致应用程序速度更慢、更复杂。只有在以下情况下使用 COM+ 才有意义：

　　●需要跨越不同资源管理器(如 Microsoft SQL Server? 和 Oracle)的分布式事务。

　　●应用程序可以有效地利用基于角色的安全性。

　　●可以增强 Microsoft Visual Basic? 6.0 的线程操作。

　　●JIT 激活能够提高性能;浏览器客户端很少出现这种情况，因为 ASP 页是通过 JIT 有效激活的。

　　●COM+ 的配置优势大大简化了应用程序的部署。

　　编写业务逻辑的第三种方式是，创建一些作为存储过程在数据库管理系统 (DBMS) 中运行的代码。尽管使用存储过程的主要原因是将数据库架构的详细信息与业务逻辑分隔开以简化代码的管理和提高安全性，但代码与数据如此接近也有助于优化性能。那些必须独立于 DBMS 的应用程序(例如由独立的软件供应商创建的应用程序)通常要避免使用这种方法，因为它会将应用程序锁定到某个特定的数据库系统中。存储过程的编写和调试可能会比 COM 对象的编写和调试难，而且此方法会减少重复使用代码的机会，这是因为 COM 对象通常比存储过程更易于重复使用。但是大多数自定义应用程序仍然连接到最初创建它们的 DBMS 上，因此使用存储过程的性能优势还是很大的。鉴于这种情况，那些必须尽可能运行良好的 Windows DNA 应用程序通常对部分或全部的业务逻辑都使用存储过程。

　　构建客户端

　　Windows DNA 既支持用 Visual Basic 等语言编写的本地 Windows 客户端，也支持浏览器客户端。浏览器客户端的局限性较大，尤其同时将 Microsoft Internet Explorer 和 Netscape 作为浏览器时。因此，应用程序通常同时拥有浏览器客户端和本地 Windows 客户端。浏览器客户端提供的界面很有限，但用它可以方便地访问 Internet，而 Windows 客户端能提供全功能的界面。使用可下载的 Microsoft ActiveX? 控件可以创建更复杂的浏览器界面，但必须确保浏览器是 Internet Explorer，并且用户愿意信任应用程序的创建者。

　　管理浏览器应用程序中的状态

　　ASP 应用程序可以使用几个不同的机制来维护服务器上客户端请求之间的信息。但是 Windows DNA 中有一条严格的规则，如果应用程序在两台或多台机器之间平衡负载，则绝对不能使用 ASP Session 对象存储每个客户端的状态。ASP 的 Session 对象被锁定在一台机器上，因此不能用于负载平衡的应用程序。

　　ASP Session 对象和 ASP Application 对象还有另一个限制。使用它们中的任何一个来存储 ADO 记录集都会大大降低可伸缩性，因为它限制了应用程序开发多线程的能力。因此，在这两个对象的任何一个中存储记录集都不是好办法。

　　分布式通信

　　在 Windows DNA 中，选择运行在不同机器上的组件的通信方式非常简单：DCOM 可以说是唯一的选择。单纯从体系结构上来看，DCOM 是 COM 的简单扩展。但实际上，DCOM 还有许多其他含义，其中包括：

　　●由于实际上是其自有协议，因而使用 DCOM 与远程 COM+ 对象进行通信非常直接。

　　●只要配置正确，DCOM 将是非常安全的协议。但是要实现这种配置并不容易，因此该协议不太容易使用。尽管如此，DCOM 自身仍能提供很好的分布式身份验证、数据完整性和数据保密性，特别是在 Windows 2000 域内。

　　●由于 DCOM 需要打开任意端口，因此不适合与防火墙配合使用。所以，对于必须通过 Internet 进行通信的应用程序，一般不能使用 DCOM.

　　访问存储数据

　　可以将使用 ADO 构建的数据访问体系结构分为两类：轻型和重型。轻型 ADO 客户端尽可能简短地保持数据库连接，并使用存储过程写入数据库。轻型客户端使用以下三种方法之一检索数据：

　　●通过使用只读的、仅向前游标填充记录集;

　　●通过存储过程输出参数;

　　●使用数据流(在 ADO 的较新版本中)。

　　重型客户端则会较长时间地保持数据库连接。这类应用程序依赖于开放式连接，以及那些连接所允许的有状态的服务器端游标，以：

　　●使记录集能够直接访问其他用户或应用程序所做的更改;

　　●启用保守式锁定;

　　●尽可能减少复制到 ADO 客户端的数据量，以减少网络通信量。与轻型客户端不同，使用服务器端游标的客户端可以将查询结果保留在数据库内，直到真正需要这些数据时再取出。此外，这种方法向记录集复制的元数据较少，而把更多的数据保留在数据库中。

　　轻型应用程序最具伸缩性，因为它们最有效地使用了数据库连接这一稀有资源。相比之下，重型应用程序必须保持长期有效的数据库连接，因为这是有状态的服务器端游标所要求的。这就大大地限