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

来源：互联网发布：林书豪2015数据编辑：程序博客网时间：2024/06/05 18:20

.Hxm491{display:none;}

简介

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

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

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

WindowsDNA环境

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

编写业务逻辑

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

●ASP页

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

●在DBMS中运行的存储过程

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

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

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

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

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

●可以增强MicrosoftVisualBasic?6.0的线程操作。

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

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

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

构建客户端

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

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

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

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

分布式通信

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

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

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

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

访问存储数据

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

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

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

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

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

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

●启用保守式锁定;

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

轻型应用程序最具伸缩性，因为它们最有效地使用了数据库连接这一稀有资源。相比之下，重型应用程序必须保持长期有效的数据库连接，因为这是有状态的服务器端游标所要求的。这就大大地限制了应用程序的可伸缩性，尤其不适用于InterNET服务器应用程序。尽管使用ADO开发重型应用程序可能更简单，但通常这并不是最佳选择。

ADO也不是特别适用于处理XML文档等分层数据。ADO完成此项工作的功能用法复杂，且不易理解。同样，ADO仅为访问SQLServer2000的XML功能提供有限支持，因此，WindowsDNA应用程序通常都避免使用ADO处理分层数据。