竞拍网站毕业设计中文翻译.doc

基于.Net Framework的N层分布式应用开发一、分布式处理概述 分布式处理是将应用程序逻辑分布到2台或者更多台计算机上，在物理上或逻辑上分离的单元中。这一概念并不是新生事物，在大型工程已经得到广泛使用。只不过，Internet的出现为分布式处理赋予了新的特征，Internet内部连接的特性可以让成百上千的计算机为一个任务工作，使得在更大规模上实施分布式处理成为可能，并跨越了传统的B/S（客户机/服务器）模型。 分布式处理思想经历了很长的过程，不同IT时代的开发人员、各级供应商做了大量的工作，使得支持分布式处理的协议极为丰富。 1、 DCOM/CORBA 在.Net Framework之前，基于组件的分布式计算的主要协议是CORBA(Common Object Request Broker Architecture,通用对象请求代理结构)，它来自Object Management Group(对象管理组)，还有Microsoft的DCOM（Distributed Component Object Model，分布式组件对象模型）。 DCOM是面向连接的。DCOM客户机持有对DCOM服务器的连接。这种连接方式导致了技术问题存在。例如，客户机可能持有引用信息，只有在用户单击按钮时生成调用。时间一长，服务器就会因等待客户机的请求而空闲。当客户机崩溃而无法请求服务器时，就会产生严重的后果。另外，在Internet上，DCOM或者CORBA服务器由数千台客户机使用，由于每一台客户机都有一个与服务器的连接，对于很少使用服务器或者根本不再使用服务器的客户机，应该保护宝贵的服务器资源。 尽管DCOM有办法处理这些问题，但是增加了许多复杂性，这也是Web服务试图解决的问题之一。 2、Web 服务 随着Microsoft .Net Framewwork的推出，实现分布式处理有了新的技术，即Web Service（Web服务）。Web服务能够为另一个应用程序而不仅仅是浏览器提供数据，并通过外置数据以允许其他的客户机使用在同样的端口和传输层都起作用的标准协议（如HTTP）来执行操作。 二、Web Service-.Net Framework下的分布式处理技术 在.Net Framework中，Web服务指是以独立于平台的方式，通过标准的Web协议，可以由程序访问的应用程序逻辑单元。 .Net Framework的开发者们将Web服务定位于基于开放的标准，能够用于任何平台。使它拥有作为跨平台和跨供应商的集成技术的潜力。实现了Web服务和Web服务构架后，用户就可以利用Internet上许多现有技术。Web服务成功的关键在于它基于开放的标准，诸如Microsoft、IBM和Sun等主要供应商都支持这些标准。 1、DCOM/CORBA面临困难之解决方案-Web服务 DCOM和CORBA在使用运行于相同平台的软件和紧密管理的局域网创建企业应用程序时非常优秀。但是，他们在创建跨平台 、跨Internet、适应Internet的可伸缩性的应用程序时力不从心。他们不是为完成这些目标而设计的。 大多数公司面临的现实情况是他们拥有来自多个供应商的多种平台。运行于不同平台上的应用程序系统间通信困难。在与商务伙伴合作时，基于传统分布式的架构合作困难。 DCOM和CORBA的问题是用户基本上要依赖一个供应商。如果要使用DCOM，就必须使用Microsoft Windows来运行服务器和客户机。尽管有其他平台上的DCOM实现方式，但是他们未被广泛采纳。虽然CORBA是由多个供应商实现的规范，互操作性仍只能以简单的方式完成，至于DCOM和CORBA间的集成就不必说了。 从技术方面看，Web服务试图解决使用诸如CORBA和DCOM这样紧密捆绑的技术时遇到的问题。这些问题包括如何通过防火墙，协议的复杂性，异类平台的集成等。 2、Web服务在分布式处理中的应用 Web服务是一种优秀的分布式处理技术。 下图演示了在.Net Framework下进行分布式处理的一般情形。作为客户端应用程序可以是传统的Windows Form应用程序、基于Web的A应用程序、蜂窝式移动应用程序等，还可以是另外的Web服务程序。这些客户端应用程序构成N层模型中的表示层（图中左列）用于数据显示。中间列是中间层，处理商务逻辑；右列是数据层，处理数据存储。随着一个基于xml的名为简单对象访问协议SOAP（Simple Object Access Protocol）的不断标准化，web服务正成为一个可以和其他服务器和应用程序交互、可行的方法。 3、N层模型下客户机消费Web服务 下图演示了客户机消费Web服务的情形。客户机可以是一个Web应用程序、另一个Web服务、诸如Microsoft Word的字处理程序等。 Web服务的消费者调用名为Method()的Web服务上的方法。实际调用向下层传播，作为Soap消息通过网络，并向上层传播到Web服务。Web服务执行并响应（如果有的话）。 实现Web服务与客户机之间的双向通知或者发布/订阅功能是可能的，但是必须手工完成。客户机可以实现自己的Web服务并在对服务器的调用中传递该Web服务的引用。服务器可以保存引用，然后回调给客户机。 三、基于.Net Framework的N层构架设计 面向对象的、基于模块化的组件设计需要能够方便地修改应用程序的各个部分。完成这一目标的一种好方法就是在层上工作，将一个应用程序的主要功能分离到不同的层或者级中。.Net Framework为创建可维护、可扩展的层模式提供了丰富的支持，使得N层够架取代传统的客户机/服务器模式而与Internet紧密结合。 1、分层模型 从本质上讲，层代表了一个应用程序主要的功能。一般地，我们将应用程序功能分为三个方面，对应3层架构模式。它们是数据层（data layer）、商务层（business layer）和表示层（presentation layer）。 数据层：包含数据存储和与它交互的组件或服务。这些组件和服务在功能上和中间层相互独立（尽管在物理上不必一定相互独立-它们可以在同一台服务器上）。 中间层：包括一个或者多个组件服务，它们应用商务规则、实现应用程序逻辑并完成应用程序运行所需要的数据处理。作为这个过程的一部分，中间层负责处理来自数据存储或者发送给数据存储的数据。 表示层：从中间层获得信息并显示给用户。该层同时也负责和用户进行交互，比较返回的信息并将信息回送给中间层进行处理。 可见，数据层从数据库中获得较为原始的数据，商务层把数据转换成符合商务规则的有意义的信息，表示层把信息转换成对于用户有意义的内容。 这种分层设计方式很有用，因为每一层都可以独立地修改。我们可以修改商务层，不断地从数据层接受相同的数据，并把这些数据传递到表示层，而不用担心出现歧义。我们也可以修改表示层，使得对于站点外观的修改不必改动下面的商务层逻辑。 2、常用的N层模型设计 已经知道，一个N层应用程序中的层不是由运行应用程序的物理结构（硬件）定义的。层是应用程序运行的一个逻辑方面的功能，并定义应用程序将执行的不同的任务阶段。这里的N层设计与经典的客户机/服务器架构截然不同。 1）、设计一个简单的3层 最简单的N层模型就是3层。这里，我们已经有一个被网络分隔开的服务器和客户机。服务器中含有数据存储和组成数据层的数据访问组件，已经组成中间层的商务逻辑。客户机作为表示层只需要给应用程序提供界面即可。 在这个最简单的情况中我们或许有一个关系数据库或者一组访问数据的组件或者存储过程。然后我们应当有一个访问组件或者存储过程的页面来提取信息，处理和格式化信息使之适合于特定的客户机，然后通过网络将信息传送给客户机。客户机所要做的事情就是显示信息、收集用户的输入和将信息回送给中间层。 2）、设计一个更接近现实的3层 然而前面的示例只是非常小的应用程序的一般情况，现实世界中很难碰到。数据存储通常位于专门选择和经过专门设置的硬件上。它也许是在运行SQL Server的基于Windows的一组服务器上，但是也可能是运行非Windows平台或Oracle或者其他的数据库服务器上。 在这种情况下，数据层和中间层之间的分离就更加显而易见-它们之间通过网络连接。并且，商务逻辑被限制在执行所有中间层数据处理的服务器上。 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仍还在服务器上，不过客户机的应用程序也可以使用它。在这种情况下，我们实际