UML软件工程组织

摘要：本文概要介绍 .NET 应用程序中的各种典型物理结构之间的区别，这些结构已被证明是很有用的。针对每种结构介绍了其适用方案、实现方式和优缺点。本文同时介绍了两层、三层和 N 层应用程序。

注意： 本文所介绍的应用程序设计问题在 MSDN® 的 Building Distributed Applications with .NET（英文）部分中进行了更深入的讨论。

目标

了解 Microsoft® .NET 应用程序的典型结构。
了解在每种结构内进行开发的优缺点。

前提条件

熟悉 .NET 开发（包括 Web 开发和桌面开发）。
熟悉编程概念（包括类和属性）。
熟悉各种结构（包括多层和多服务器结构）。

两层应用程序结构使用 XML Web Service 的三层应用程序使用 .NET Remoting 的三层应用程序逻辑 N 层应用程序使用 XML Web Service 的 N 层应用程序其他 N 层应用程序技术迁移 Visual Basic 6.0 的 N 层应用程序小结

两层应用程序结构

典型的两层应用程序是使用 ADO.NET 直接与数据库服务器（如 Microsoft SQL Server™）进行通信的客户端应用程序（参见图 1）。除 ADO.NET 外，在客户端应用程序和数据库之间没有任何其他层。有关 ADO.NET 的详细信息，请参阅 .NET 框架文档、本系列的其他文章或使用 MSDN 搜索引擎。

图 1：两层应用程序包括客户端应用程序和数据存储（如 Microsoft SQL Server）

何时使用两层结构

两层应用程序适用于没有或只有少量窗体的小型应用程序。对于使用本文中介绍的其他 N 层技术的应用程序，其原型也可算是两层应用程序。但是，两层应用程序不太适用于企业环境，因为开发和维护的时间及成本不好控制。

典型的实现方式

开发两层应用程序时可以采用多种技术。所有技术均使用 ADO.NET、一个客户端界面（如桌面或基于 Web 的应用程序）和一个数据库（如 SQL Server）。要使用两层应用程序结构，可以采用以下方式：

使用数据绑定技术将 ADO.NET 数据集直接与控件连接。
编写代码以访问 ADO.NET 对象，从而手动将数据加载到用户界面的控件中。
使用上述两种技术的组合。
使用上述任何技术直接在窗体上编写业务规则代码。

优点

两层应用程序具有以下优点：

因为可以使用数据绑定将 ADO.NET 数据集直接与用于构建用户界面的很多控件连接，所以开发工作就变得简单而快捷。这有助于迅速建立并运行应用程序的基本功能。
只需查看窗体便可以浏览应用程序的全部代码，而无须同时查看窗体和另一个组件。

缺点

两层应用程序开发方法具有以下缺点：

所有业务规则均包含在前端代码中。因而，如果需要更改业务规则，则必须更新全部客户端。除非能够进行自动更新，否则这种维护工作将十分繁琐。当然，如果使用 SQL Server，则可以将某些业务规则放到存储过程中，从而减少维护的时间和成本。
尽管 SQL 可以在数据库结构和应用程序的其他部分之间提供某种程度的精简，但字段名称通常还是在源代码或控件属性中硬编码的。如果更改字段名称，则必须查找和替换应用程序中所有该字段的名称。如果使用了数据绑定，还必须检查所有窗体并更改属性。
很多代码（如 SQL 语句和业务规则）常常在应用程序中重复出现，这是因为不同的窗体使用了某些相同的表。这使得此类应用程序的维护非常困难，因为如果需要更改表或字段的名称，则必须在多个位置进行更改，同时还需要在多个位置进行额外的回归测试。
如果数据源发生变化，则对用于将数据加载到数据集的代码的更改将更加困难。例如，如果原来使用文本文件存储数据，然后又希望转换到 SQL Server，其访问方式是截然不同的。此外，要将数据加载到应用程序的数据集，还有很多地方都需要更改代码。

使用 XML Web Service 的三层应用程序

另一种设计方式是使用 XML Web service，将数据库的访问单独分给另一个组件，该组件将把数据返回到前端应用程序。图 2 显示了这种设计方式。

有关使用 XML Web services 开发三层应用程序的详细信息，请使用 MSDN 搜索引擎。

图 2：使用 XML Web service 将数据库层与前端代码分离

何时使用此技术

使用 XML Web service 的三层应用程序适用于基于 Web 的应用程序或 Microsoft Windows® 应用程序。如果需要桌面应用程序的丰富功能，而用户连接自多个不同的位置，并通过 HTTP 界面访问数据，则很适合使用此技术。

典型的实现方式

要创建三层/XML Web service 应用程序，通常采用以下开发技术：

所有 SQL 驻留在 XML Web service 中。在服务器上构建数据集，并将其作为 XML 流返回到客户端，它们在这里又可以重新被构建为数据集。
可以将从 XML Web service 返回的数据集直接绑定到窗体的控件中。
可以使用从 XML Web service 返回的数据集手动将数据加载到窗体的各种控件中。
直接在窗体上编写所有业务规则的代码。

优点

使用 XML Web service 的三层应用程序具有以下优点：

因为可以使用数据绑定将 ADO.NET 数据集直接与用于构建用户界面的很多控件连接，所以开发工作就变得简单而快捷。这有助于迅速建立并运行应用程序的基本功能。
用户可以从能连接到 Internet（或 Intranet）的任何地方运行应用程序。
数据库访问被单独分给自己的组件，这样就无需在前端代码中嵌入 SQL。
连接信息只保留在 XML Web service 上，同样减少了客户端计算机的维护工作。
可以在某个中心位置更新数据库访问层。如果对此层进行简单的代码更改，则无需重新向客户端分发组件。

缺点

此设计的缺点与典型的两层应用程序的缺点基本相同，因为它并没有分离业务规则，而只是分离了数据层。此外，表中的列名称也没有被提取到类中（将在下一节中介绍）。

所有业务规则均包含在前端代码中。因而，如果需要更改业务规则，则必须更新全部客户端。除非能够进行自动更新，否则这种维护工作将十分繁琐。当然，如果使用 SQL Server，则可以将某些业务规则放到存储过程中，从而减少维护的时间和成本。
所有字段名称均在源代码或控件属性中硬编码。如果更改字段名称，则必须查找和替换应用程序中所有该字段的名称。如果使用了数据绑定，还必须检查所有窗体并更改属性。
通过 HTTP 界面进行访问比直接连接数据库要慢。
如果用户无法访问 Internet（或 Intranet），则无法使用该应用程序。

使用 .NET Remoting 的三层应用程序

这种类型的应用程序结构与使用 XML Web service 的三层应用程序几乎完全相同。唯一的区别是使用 .NET Remoting 代替 XML Web service 来包装数据访问层。图 3 显示了这种设计方式。

有关 .NET Remoting 的详细信息，请参阅本系列的其他文章或使用 MSDN 搜索引擎。

图 3：在 LAN 环境中，可以使用 .NET Remoting 来包装数据访问层

何时使用三层 .NET Remoting 技术

使用 .NET Remoting 的三层应用程序适用于必须在 LAN 中的计算机之间分布的应用程序。这可能是出于业务原因，或者考虑到所涉及的工作成本，采用网络呼叫比较合理。

典型的实现方式

要创建这种应用程序，通常采用以下开发技术：

所有 SQL 驻留在通过 Remoting 服务调用的组件中。在服务器上构建数据集，并将其作为 XML 流返回到客户端，它们在这里又可以重新被构建为数据集。
将从 Remoting 组件返回的数据集直接绑定到窗体的控件中。
使用从 Remoting 组件返回的数据集手动将数据加载到窗体的不同控件中。
直接在窗体上编写所有业务规则的代码。

优点

使用 .NET Remoting 的三层应用程序与使用 XML Web service 的三层应用程序具有相同的基本优点。

因为可以使用数据绑定将 ADO.NET 数据集直接与用于创建用户界面的很多控件连接，所以编写三层应用程序就变得简单而快捷。这有助于迅速建立并运行应用程序的基本功能。
用户可以从能连接到 LAN 或 WAN 的任何地方运行应用程序。
数据库访问被单独分给另一个组件，这样就无需在前端代码中嵌入 SQL。
可以在某个中心位置更新数据库访问层。如果在此组件中进行简单的代码更改，则无需重新向客户端分发组件。
注意： 所有 N 层结构都具有此优点。

缺点

这种三层设计的缺点与使用 XML Web service 的三层设计的缺点相同。

所有业务规则均包含在前端代码中。因而，如果需要更改业务规则，则必须更新全部客户端。除非能够进行自动更新，否则这种维护工作将十分繁琐。当然，如果使用 SQL Server，则可以将某些业务规则放到存储过程中，从而减少维护的时间和成本。
所有字段名称均在源代码或控件属性中硬编码。如果更改字段名称，则必须查找和替换应用程序中所有该字段的名称。如果使用了数据绑定，还必须检查所有窗体并更改属性。
通过网络从一个组件向另一个组件传输数据比直接连接数据库要慢。在 Intranet 方案中，.NET Remoting 的性能比 XML Web service 要好。而在 Internet 方案中，一般不使用 .NET Remoting。
建立这种应用程序比建立两层应用程序或使用 XML Web service 的应用程序要复杂一些。

逻辑 N 层应用程序

使用 .NET 创建应用程序的最好方法是将所有逻辑进程分为不同的类。在典型的业务应用程序中，这通常包含业务规则组件、数据层组件和使用这些组件的前端代码。图 4 显示了这一方法。

有关设计 N 层应用程序的详细信息，请参阅本系列的其他文章或使用 MSDN 搜索引擎。

图 4：将业务进程分解为不同的类，从而使应用程序更易于创建和维护

何时使用 N 层结构

逻辑 N 层开发策略适用于所有类型的应用程序。无论是小型、中型、大型应用程序，还是桌面或 Web 应用程序，效果都很好。

典型的实现方式

要创建这种应用程序，通常采用以下开发技术：

使用 Windows 窗体或 Web 窗体创建前端用户界面。
使用单独的类库项目创建业务规则组件。
使用单独的类库项目创建数据层组件。此数据层使用类来包装对各个表的访问。应当使用类型化数据集；它们提供了灵活的数据集类，并且为表中的每个列提供了严格的类型检查功能。

优点

逻辑 N 层应用程序具有以下优点：

将业务规则集中到易于创建、使用和重用的组件中，从而方便了开发和维护。
提供了高级语言以开发业务规则，代替使用存储过程和有限的 SQL 语言来检查业务规则。
将数据访问集中到组件中，从而减少了应用程序中的重复代码，每个需要访问特定表的窗体都使用相同的组件。
如果使用类型化数据集，则可以使用智能感知功能来查询列名称，而不必记住它们。
集中式数据访问例程有助于维护工作，因为对任何数据访问例程的更改都只需进行一次即可。
可以随时将组件分离到不同的物理计算机上。这种灵活性使代码具有更好的可缩放性和集中性。

缺点

逻辑 N 层应用程序只有两个较大的缺点：

开发时间稍长，因为必须构建单独的组件。
需要跟踪的组件会多一些。这使其略显复杂，对于编程新手来说可能不太好理解。

使用 XML Web Service 的 N 层应用程序

图 5 显示了如何进行逻辑 N 层应用程序设计并将其分布于多台计算机的示例。在此图中，可以看到使用了 XML Web service 来访问数据层。类型化数据集通过 HTTP 层返回到业务规则层。然后，客户端应用程序可以将该数据集用于用户界面的数据显示。

图 5：将业务进程分离到单独的计算机中以利于部署和维护

何时使用此技术

如果需要桌面应用程序的丰富功能，而用户可能连接自很多远程位置，并且需要通过 HTTP 界面来获取数据，那么就可以采用这种 N 层 XML Web service 应用程序设计。将业务规则保留在客户端上有利于网络畅通，但如果这些规则更改频繁，则会增加一些维护更新工作。由于 .NET 可以复制新的 DLL 而无需注册，所以这些问题已经不象在以前的技术中那样严重。

这种方案也适用于基于 Web 的应用程序，其中由一台 Web 服务器提供数据，而由另一台 Web 服务器上的 Web 应用程序显示此数据。

典型的实现方式

要创建这种应用程序，通常采用以下开发技术：这些技术与逻辑 N 层应用程序中的技术相同。

使用 Windows 窗体或 Web 窗体创建前端用户界面。
使用单独的类库项目创建业务规则组件。
使用单独的类库项目创建数据层组件。此数据层使用类来包装对各个表的访问。应当使用类型化数据集；它们提供了灵活的数据集类，并且为表中的每个列提供了严格的类型检查功能。

优点

使用 XML Web service 的 N 层应用程序具有多个优点，其中很多与逻辑 N 层应用程序相同。

将业务规则集中到易于创建、使用和重用的组件中，从而方便了开发和维护。
提供了高级语言以开发业务规则，代替使用存储过程和有限的 SQL 语言来检查业务规则。
将数据访问集中到组件中，从而减少了应用程序中的重复代码，每个需要访问特定表的窗体都使用相同的组件。
如果使用类型化数据集，则可以使用智能感知功能来查询列名称，而不必记住它们。
集中式数据访问例程有助于维护工作，因为对任何数据访问例程的更改都只需进行一次即可。
可以随时将组件分离到不同的物理计算机上。这种灵活性使代码具有更好的可缩放性和集中性。
其他优点：集中式数据访问层。
其他优点：应用程序的可扩展性 - 可以添加 Web 领域以处理用户对数据库的请求的大量负载。
其他优点：用户可以通过 Internet 进行连接，但仍从桌面或基于 Web 的应用程序访问数据。

缺点

使用 XML Web service 的 N 层应用程序开发方法也有一些缺点。其中大部分与使用逻辑 N 层应用程序开发方案的缺点相同。

开发时间稍长，因为必须构建单独的组件。
需要跟踪的组件会多一些。这使其略显复杂，对于编程新手来说可能不太好理解。
如果 XML Web service 不能正常工作，该应用程序将无法使用。

其他 N 层应用程序技术

当然，可以采用很多不同的技术来创建 N 层应用程序。例如，可以使用 .NET Remoting 在客户端层和业务规则层之间进行通信，如图 6 所示。

图 6：可以组合使用 .NET Remoting 和 XML Web services，为应用程序提供最佳的可缩放性和可维护性

使用 N 层技术开发应用程序后，还可以采用多种方法对其进行配置。可以组合使用 .NET 中的任何可用方法来分离应用程序的各层。

迁移 Visual Basic 6.0 的 N 层应用程序

程序员在以前版本的 Microsoft Visual Basic® 中使用 N 层技术已经有很多年了。如果有现成的 COM 组件，则可以很容易地为这些组件上加上 .NET 包装。之后，便可以获得如图 7 所示的结构。

有关在 .NET 中使用 COM 组件的详细信息，请参阅本系列的其他文章或使用 MSDN Web 站点中的搜索引擎。

图 7：使用 .NET 可以方便地建立原有 COM 组件的接口

何时使用 Visual Basic 迁移技术

如果具有大量的 COM 组件代码，并且这些组件已经包含了您的业务规则和数据访问例程，则适合使用这种技术。因为可以利用很多现有代码，从而降低进入 .NET 框架的成本。

典型的实现方式

要创建这种应用程序，通常采用以下开发技术：

使用 Windows 窗体或 Web 窗体创建前端用户界面。
设置对原有 COM DLL 的引用。Microsoft .NET 自动为此 DLL 创建一个 .NET 包装，因此可以象对任何 .NET 组件那样访问其属性和方法。
如果从该 DLL 中返回任何 ADO 记录集，则可以将它们转换为数据集，这是绑定到 .NET 控件的最简单的方法。

优点

在 COM 接口外加上 .NET 包装，可以在使用现有代码的同时充分利用 .NET 的新功能，从而缩短开发周期。

缺点

在 .NET 中使用 COM 包装具有以下缺点：

其性能不如完全在 .NET 中编写的代码。
可能需要额外的代码以将 ADO 记录集转换为 ADO.NET 数据集。

小结

在开发 .NET 应用程序时，可以采用的结构形式几乎是无限的。易于创建和维护的结构才是最好的。当然，还要考虑其他设计目标，包括可缩放性、可靠性和可管理性等。在 MSDN 中，您可以找到许多相关主题的白皮书。

关于作者

Paul D. Sheriff 是 PDSA, Inc. 的所有者。该公司位于南加利福尼亚州，是一家自定义软件开发和咨询公司。Paul 是南加利福尼亚州的 MSDN 地区总监，著有《Paul Sheriff Teaches Visual Basic》一书，并为 Keystone Learning Systems 制作了至少 72 套关于 Visual Basic、SQL Server、.NET 和 Web 开发的视频教材，Paul 还是《ASP.NET Jumpstart》（英文）的作者之一。有关详细信息，请访问 PDSA, Inc. 的 Web 站点 www.pdsa.com。

关于 Informant Communications Group

Informant Communications Group, Inc. (www.informant.com) 是一家专注于信息技术行业的多媒体公司。它成立于 1990 年，主要从事于软件开发出版物、会议、目录发布和 Web 站点。ICG 在美国和英国均设有办事处，目前已成为享有盛誉的媒体和营销内容集成商，满足 IT 人员对高质量技术信息不断增长的需求。