3、.Net Framework下的层间(远程)传输对象及技术
.Net Framework实现了许多新的技术以支持多层分布式处理，它提供了丰富的类库、对象及方法使得在不同层(物理上分离或仅仅是逻辑上分离)间的数据传输更为简单。
1）、支持远程数据传送的对象：
l ADO.NET DataSet对象
l ADO.NET DataTable对象
l XmlDocument对象
l XmlDataDocument对象
2）、支持远程数据传送的类/方法：
l Serialization类
Serialization类描述了一个将数据转换为一种能复制到另一个过程的格式的对象的过程。前面提及的可远程传输的对象具有串行化整个内容的能力，以便它可以通过一个通道来传送。这个通道可以直接通过TCP/IP，或者通过HTTP。当然，它们也可以在另一端解除串行化，因此客户机就得到一个原对象的完整副本。
l System.Runtime.Remoting类
System.Runtime.Remoting命名空间提供的对象可用来为对象创建代理以实现远程数据传送。在这种情形下，对象保留在服务器上，并且客户机只收到一个代理对象的引用。这个代理对象表示原来的基于服务器的对象（这就是我们怎样远程使用一个DataReader的方法），示意如下图：
对于客户机，这个代理提供了与原始对象相同的方法和属性。然而，当客户机与代理对象相互作用时，调用被自动串行化，并通过通道（网络）传送给服务器上的对象。然后，任何响应和结果通过通道被传送回客户机。
这两个远程技术都允许客户机使用原来在服务器上创建的对象。我们能够串行化一个DataSet对象或者Xml文档，同时我们也能串行化其它的如集合这样的对象--比如一个哈希表(Hashtable)或数组(Array)。
4、N层模型中的数据处理及对象选择
首先需要考虑的是希望从数据存储中提取出来的数据做些什么？这个问题的答案对我们所使用对象的基本选择的影响将比其他任何事情都要大，甚至在某种程度上定义了我们希望完成任务的性能的种类。
1）、只用于显示的数据
如果只是想以一种固定格式为终端用户显示数据的话，一般来说根本就没有必要远程传输数据。我们没有必要在线上将所有的数据传送给客户机--我们只能传给它们客户设备能接受的任何格式的最终显示信息。
在这种情形中，"Reader"对象提供了一种只读的、仅向前的理想且性能最优的技术。当与能实现服务器端数据绑定的服务器控件一起使用时，我们可以获得一个显示数据的高效方法。
2）、需要远程传输的数据
然而，如果我们需要远程传输数据的话则存在一个问题。这些快速而高效的"Reader"对象只在作为一个引用时才能被远程传输。将一个DataReader作为引用传送给一个客户机时，DataReader仍还在服务器上，不过客户机的应用程序也可以使用它。在这种情况下，我们实际上并没有远程传输数据，而是使用了一个远程传输对象。在很多情况下都存在这种情况。
要实现数据的远程传送，应该将数据寄存到一个能够存储（或保持）数据的对象中。并允许代码不需进入数据存储的额外行程就可以根据需要提取数据，并且多次读取。在ADO.NET中，这个对象就是DataSet对象（或者DataTable对象）。当使用xml时，也有几个对象供选择。我们能够远程传输XmlDocument和XmlDataDocument对象。这两个对象都有保持内容的能力，并且可以在一个应用程序的层之间进行传送。
四、N层分布式数据处理架构模型
要进一步理解怎样在应用程序中划分不同的层，需要确定数据如何显示以及是否需要更新数据和向服务器及时返回更新。
1、全部在服务器上完成显示
在客户机上显示数据，最常见的情形是在一组或者多组服务器上执行所有的数据处理。数据层和中间层限于服务器，客户机只提供显示接口。对于一个web浏览器来说，通常的格式为html，对于一个蜂窝式电话或类似设备来说，可能是以wml格式表示，等等。
下图使用一个存储过程或SQL语句来提取所需要的数据，然后用asp.net进行处理，或者执行一个web服务。另外，这里也用xml片段的形式从数据存储中提取数据，然后对数据进行处理并提供给客户机。
如果以xml文档形式存储数据，或者以这样一种格式存储数据：数据作为xml外置数据层，那么我们就有一些其他的选择。
下图显示了怎样提取和处理xml数据以便传送给客户机使用。此外，数据的提取其实就是借助一个"Reader"对象，并且可以使用不同的技术来处理数据并将数据提供给客户机。
2、扩展中间层
虽然数据的提取和处理经常在一个对象里发生，比如一个Asp.Net页面，但是为了有效利用由于使用基于组件的设计而提供的好处，通常需要提供更为精细的架构。我们应该有在显示数据或者将其传送给客户机之前应用于数据的商务规则。换句话说，它可能是因为安全的原因，也可能是为了实现分布式处理，或者只是提供可重用性和使应用程序的维护更加容易。
例如，应该有访问一个数据存储并提取一系列消费者的多个页面。通过在一个独立于asp.net页面或其他提供数据给客户机的对象的组件中建立这个过程，我们能够提供一个提取数据的层。然后，我们在将来需要在某些方面改变数据存储或者数据结构，或者改变访问它的规则，我们只要用一个新的版本替换组件即可。
只要组件的接口仍然未变，所有使用这个接口的应用程序将看到来自组件的相同输出并和以前一样继续运行。然而，组件在内部用来提取和处理来自数据存储的数据的方法可以根据需要进行相应修改。下图示意了这种架构。
显然，该过程可以使用多个组件。如果数据的提取相当复杂，或者同一数据运用在多个地方的话，进一步分解数据处理（分解为更多组件层）就很有意义。例如，可用一个组件将数据当作一系列包含所有必须列的行（以关键字顺序排列），这个组件就可以成为其他以不同顺序存储数据的组件，或者仅外置数据的某些列的组件的数据源。
3、移动数据处理到客户机
一般地，要获得发送给客户机的数据，我们将利用客户端脚本（JavaScript或 VBScript以及 WMLScript）、用Java或者一个特定平台的语言书写的客户端组件，或者用诸如Visual Basic 6.0、C++、Delphi等语言书写的客户端可执行程序等等。当然，所有我们需要的功能都是.Net Framework的一部分。（用户可通过下载和安装可重新分配的Framework（大约5MB）在客户机上使用Framework）。
因此，下面的示意图显示了一些用于实现获得发送给客户机的数据并在客户机上进行处理的方法。
4、将更新回送给服务器
在许多情况下，如果我们的要求就是以一种尽可能快速和高效的方式获得发送给客户机的依据，那么，上面的示例能很好地完成任务。然而，许多应用程序要求客户机将数据回送以更新数据存储等操作时，就需要寻找更合理的模式。
至少有三种方法用于向服务器端回送数据。一是回送Html表单和查询字符串(实现方式与以前的ASP类似)；另一是客户端组件(例如IE5及以上版本的XMLHTTP组件)；还有就是客户端可执行的Windows表单应用程序和服务等。
因此，应该有这样一种情况：客户机仅仅要求我们发送一些数据，并且我们让客户机完成所有的数据处理。也就是说，客户机充当某种类型的服务，它将应用程序的数据作为自己的源数据来使用，然后在它的客户机已经处理数据后将更改提交回来。
一旦客户端完成了数据更新，或者已经收集了用户输入的新数据，客户机应用程序就以一种合适的格式打包数据（或者用正确的技术整理数据），并将它提交给服务器进行处理和存储。
下图显示了利用"胖客户机"来实现这种架构的方法，其中数据在客户机上进行处理，然后经整理后返回给服务器来更新原始的数据存储。
仍然地，这不是一个包含所有可能性的图表。回送数据的方法或许和发送数据的方法没有什么联系。你应该根据应用程序的实际需求设计合适的模型。
五、结束语
建立可维护、可扩展的站点，开发高效率、高伸缩性的应用程序、实现跨平台、跨Internet的应用集成、创建N层分布式应用程序是摆在无数开发者面前的任务。传统开发方式及技术面临了困难。
.Net Framework推出的许多新技术为这些任务的实现提供了相对简单的解决方案。其中，基于SOAP的Web Service在处理分布式应用时具有比传统的DCOM/CORBA明显的优点，结合基于Web的ASP.NET页面开发技术和SQLServer数据存储技术（或Xml文档），在.Net下开发N层应用程序也不再困难。
