.Net Framework的N层分布应用开发(2)

 　　三、基于.Net Framework的N层构架设计

　　面向对象的、基于模块化的组件设计需要能够方便地修改应用程序的各个部分。完成这一目标的一种好方法就是在层上工作，将一个应用程序的主要功能分离到不同的层或者级中。.Net Framework为创建可维护、可扩展的层模式提供了丰富的支持，使得N层够架取代传统的客户机/服务器模式而与Internet紧密结合。

　　1、分层模型

　　从本质上讲，层代表了一个应用程序主要的功能。一般地，我们将应用程序功能分为三个方面，对应3层架构模式。它们是数据层（data layer）、商务层（business layer）和表示层（presentation layer）。

　　数据层：包含数据存储和与它交互的组件或服务。这些组件和服务在功能上和中间层相互独立（尽管在物理上不必一定相互独立--它们可以在同一台服务器上）。

　　中间层：包括一个或者多个组件服务，它们应用商务规则、实现应用程序逻辑并完成应用程序运行所需要的数据处理。作为这个过程的一部分，中间层负责处理来自数据存储或者发送给数据存储的数据。

　　表示层：从中间层获得信息并显示给用户。该层同时也负责和用户进行交互，比较返回的信息并将信息回送给中间层进行处理。

　　可见，数据层从数据库中获得较为原始的数据，商务层把数据转换成符合商务规则的有意义的信息，表示层把信息转换成对于用户有意义的内容。

　　这种分层设计方式很有用，因为每一层都可以独立地修改。我们可以修改商务层，不断地从数据层接受相同的数据，并把这些数据传递到表示层，而不用担心出现歧义。我们也可以修改表示层，使得对于站点外观的修改不必改动下面的商务层逻辑。

　　2、常用的N层模型设计

　　已经知道，一个N层应用程序中的层不是由运行应用程序的物理结构（硬件）定义的。层是应用程序运行的一个逻辑方面的功能，并定义应用程序将执行的不同的任务阶段。这里的N层设计与经典的客户机/服务器架构截然不同。

　　1）、设计一个简单的3层

　　最简单的N层模型就是3层。这里，我们已经有一个被网络分隔开的服务器和客户机。服务器中含有数据存储和组成数据层的数据访问组件，已经组成中间层的商务逻辑。客户机作为表示层只需要给应用程序提供界面即可。

　　在这个最简单的情况中我们或许有一个关系数据库或者一组访问数据的组件或者存储过程。然后我们应当有一个访问组件或者存储过程的asp.net页面来提取信息，处理和格式化信息使之适合于特定的客户机，然后通过网络将信息传送给客户机。客户机所要做的事情就是显示信息、收集用户的输入和将信息回送给中间层。

　　2）、设计一个更接近现实的3层

　　然而前面的示例只是非常小的应用程序的一般情况，现实世界中很难碰到。数据存储通常位于专门选择和经过专门设置的硬件上。它也许是在运行SQL Server的基于Windows的一组服务器上，但是也可能是运行非Windows平台或Oracle或者其他的数据库服务器上。

　　在这种情况下，数据层和中间层之间的分离就更加显而易见--它们之间通过网络连接。并且，商务逻辑被限制在执行所有中间层数据处理的服务器上。

　　3）、设计N层

　　很明显，上面的情况都假定了两件事：一是客户机为一个低端设备（因此不参与应用程序中所需的实际数据处理）；另外就是只有一组商务规则。

　　然而，这些假设并不符合实际的应用程序。例如，我们通常期望商务规则在其他某个地方而非在中间层中。在提取数据过程的前期实现某个商务逻辑比较恰当，当然我们也可以在访问数据存储的组件中实现商务逻辑。这个商务逻辑"包"因此能和数据存储在同一个服务器上，或者甚至（在一个分组的环境中）在另外一个中间路由服务器上。

　　另外，为了充分利用"胖客户机"的一些性能，以便减少网络负载和因访问路径循环而导致的迟滞，我们可以将一些商务逻辑放在客户机上。

　　下图就显示了这种变化，其中商务逻辑已经从中间层剥离并位于数据服务器或者客户机上。

　　可见，这种模式没有中间存储并且几乎不需要中间数据处理，所以效率更高。

　　4）、设计一个更加现实的N层

　　一般地，我们使用一个或者多个分离的服务器来维持我们正在使用的数据存储，这时，商务逻辑的分布更为分散。下图显示了由两个网络分离的三个机器。可以看出，现在的商务逻辑被分为三个区：一些将和数据存储运行在同一台服务器上，另一些将在中间层服务器上运行，还有一些将在客户机上运行。

　　由此可以看到，准确定义各个层并不容易。"中间层"的真正意思是商务逻辑本身，并且，商务逻辑的不同元素可以无可非议地存在于不同的服务器中。

　　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对象。这两个对象都有保持内容的能力，并且可以在一个应用程序的层之间进行传送。