从N层到.NET详细剖析原理(2)

将数据传递到客户端

　　对于所有 N 层应用程序而言，将数据从中间层有效地移动到客户端都是一个关键的环节。当使用 DCOM 与 Windows 客户端通信时，Windows DNA 应用程序可以使用 ADO 断开连接的记录集。当确保浏览器为 Internet Explorer 时，此选项也可用于浏览器客户端。而将数据发送到任意浏览器则比较困难。一种方法是显式地将数据转换为 XML，然后将数据和所有必要的脚本代码发送到浏览器。

　　.net 环境

　　.NET 支持传统的 N 层应用程序、Web Services 应用程序以及将二者的元素结合在一起的应用程序。本节首先介绍 .NET 如何影响 N 层应用程序，然后介绍构建 Web services 应用程序过程中的几个主要的体系结构问题。

　　将 N 层应用程序与 .NET 绑定在一起

　　上一节中介绍的某些问题同样适用于 Windows DNA 应用程序和使用 .NET 框架构建的应用程序。例如，只有当满足前面所列的一个或多个条件时，才能使用 COM+(在 .NET 框架中称为企业服务)。同样，将业务逻辑构建为存储过程在很多 N 层应用程序中都可以获得更好的性能。

　　同时，。NET 框架中到处都是新技术和现有技术的新版本。这些增强功能为 N 层应用程序的优化体系结构带来了多种变化。本节将按照前面介绍的分类，介绍 .NET 框架是如何改变体系结构设计人员在创建 N 层应用程序时所做的决定的。

　　编写业务逻辑

　　与在 Windows DNA 中创建 N 层业务逻辑的三种可选方法(ASP 页、COM 组件和存储过程)不同，。NET 框架只提供了两种方法：程序集和存储过程。对于浏览器应用程序，可以使用 Microsoft ASP.NET .aspx 页来创建程序集。与 ASP 不同，在这种情况下完全使用 ASP.NET 编写业务逻辑通常是一个比较好的方法。

　　其中一个原因就是 ASP.NET 的内含代码选项。在传统的 ASP 页中，以一种可维护的方式混合业务代码和表示代码并不是一件容易的事，而 .aspx 页使用内含代码能够完全将这两种代码分开。Windows DNA 应用程序可能需要同时使用 ASP 页和 COM 对象才能实现可维护性，而使用 .NET 框架构建的应用程序则只需使用 ASP.NET.此外，。aspx 页中包含的业务逻辑可以用任何基于 .NET 的语言编写，而不仅限于传统 ASP 页所支持的简单的脚本语言。而且，ASP.NET 是编译页面而不是解释页面，因此 ASP.NET 应用程序速度可以非常快。虽然使用 Windows DNA 构建的应用程序可以使用 ASP 页和 COM 对象来达到足够高的性能，但 .NET 只需使用 ASP.NET 便可构建具有同样优良性能的应用程序。最后，业务逻辑使用 ASP.NET 缓存来减少对包含常用数据的数据库的访问，这样可以大大提高性能。

　　但是，需要指出的是，对于包含在 .aspx 页中的代码，即使是使用内含代码，其重复使用也比标准的程序集困难。例如，从 Windows 窗体客户端访问 .aspx 页中的代码会遇到很多问题。

　　构建客户端

　　使用 .NET 框架可减少对 Windows 客户端的需求，通常只需要一个浏览器客户端即可。其中一个原因在于，ASP.NET Web 控件允许构建和/或购买可重复使用的浏览器图形用户界面 (GUI) 元素，从而能够更方便地构建更有用的浏览器客户端。而且可以将基于 .NET 框架的组件下载到 Internet Explorer 客户端，然后使用部分信任来运行这些组件(而不使用 ActiveX 控件所要求的全是全非信任模式)，这有助于构建更好的用户界面。

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

　　由于 ASP Session 对象被绑定到一台机器上，因此它并未发挥出应有的作用，而使用 .NET 框架就避免了这种限制。与 ASP 不同，ASP.NET Session 对象可以被两台或多台机器共享，从而可以使用 Session 对象来维护负载平衡的 Web 服务器领域中的状态，使其更加有用。而且，由于 Session 对象的内容可以选择存储在 SQL Server 数据库中，这种机制可用于出现故障时必须一直保持每个客户端的状态的应用程序中。

　　影响 ASP.NET 应用程序体系结构的另一个重要更改在于，数据集可以存储在 Session 和 Application 对象中而无需包含线程，这一点与 ASP 不同。也就是说，在 Windows DNA 中严格规定的不能将记录集存储在这些对象中的规则不适用于 .NET 框架中的数据集。这就使得查询结果的存储更加简单也更加自然。

　　分布式通信

　　与 Windows DNA 相比，.NET 框架为应用程序的分布式部件之间的通信提供了更多选择，包括：

　　●。NET Remoting，提供 TCP 通道和 HTTP 通道;

　　●ASP.NET 支持在 .asmx 页中实现的、可通过 SOAP 调用的 XML Web services;

　　●与远程 COM 对象通信所需的 DCOM.

　　选项越多，意味着体系结构的选择也越多，这也意味着做选择时有更多需要考虑的因素。使用 .NET 框架创建分布式应用程序时要了解的体系结构问题包括：

　　●直接与远程 COM+ 对象进行通信要求使用 DCOM，而不能使用 .NET Remoting.由于 DCOM 的建立和使用都相当复杂，因此应尽量避免这种通信。在某些情况下，有必要通过托管代码处理现有的 COM+ 对象，尽管这样做所要求的 COM 互操作性会降低性能。

　　●。NET Remoting TCP 通道没有提供内置的安全性。与 DCOM 不同，它不提供严格的身份验证、数据完整性或数据保密服务。但它并非一无是处，TCP 通道比 DCOM 更容易配置。

　　●DCOM 不能很好地与防火墙配合使用，。NET Remoting HTTP 通道与之不同，它是专门为在 Internet 上进行有效通信而设计的。而且，由于可以使用 SSL，此选项能够为数据提供安全的路径。通常，对于 Intranet 通信而言，TCP 通道是较好的选择;而对于 Internet 通信，则更适合使用 HTTP 通道或 ASP.NET SOAP 支持。