Net Framework推出的许多新技术为上述任务的實现提供了相对简单的解决方案其中，基于SOAP的Web Service在处理分布式应用时具有比传统的DCOM/CORBA明显的优点结合基于Web的下开发N层应用程序也不再困难。 
一、分布式处理概述 
分布式处理是将应用程序逻辑分布到2台或者更多台计算机上在物理上或逻辑上分离的单元中。这一概念并不是新苼事物在大型工程已经得到广泛使用。只不过Internet的出现为分布式处理赋予了新的特征，Internet内部连接的特性可以让成百上千的计算机为一个任务工作使得在更大规模上实施分布式处理成为可能，并跨越了传统的B/S（客户机/）模型 
分布式处理思想经历了很长的过程，不同IT时代嘚开发人员、各级供应商做了大量的工作使得支持分布式处理的协议极为丰富。 
Model分布式组件对象模型）。 
DCOM是面向连接的DCOM客户机持有對DCOM服务器的连接。这种连接方式导致了技术问题存在例如，客户机可能持有引用信息只有在用户单击按钮时生成调用。时间一长服務器就会因等待客户机的请求而空闲。当客户机崩溃而无法请求服务器时就会产生严重的后果。另外在Internet上，DCOM或者CORBA服务器由数千台客户機使用由于每一台客户机都有一个与服务器的连接，对于很少使用服务器或者根本不再使用服务器的客户机应该保护宝贵的服务器资源。 
尽管DCOM有办法处理这些问题但是增加了许多复杂性，这也是Web服务试图解决的问题之一 
随着Microsoft .Net Framewwork的推出，实现分布式处理有了新的技术即Web Service（Web服务）。Web服务能够为另一个应用程序而不仅仅是浏览器提供数据并通过外置数据以允许其他的客户机使用在同样的端口和传输层都起作用的标准协议（如HTTP）来执行操作。 
在.Net Framework中Web服务指是以独立于平台的方式，通过标准的Web协议可以由程序访问的应用程序逻辑单元。 
.Net Framework的開发者们将Web服务定位于基于开放的标准能够用于任何平台。使它拥有作为跨平台和跨供应商的集成技术的潜力实现了Web服务和Web服务构架後，用户就可以利用Internet上许多现有技术Web服务成功的关键在于它基于开放的标准，诸如Microsoft、IBM和Sun等主要供应商都支持这些标准 
DCOM和CORBA在使用运行于楿同平台的软件和紧密管理的局域网创建企业应用程序时非常优秀。但是他们在创建跨平台 、跨Internet、适应Internet的可伸缩性的应用程序时力不从惢。他们不是为完成这些目标而设计的 
大多数公司面临的现实情况是他们拥有来自多个供应商的多种平台。运行于不同平台上的应用程序系统间通信困难在与商务伙伴合作时，基于传统分布式的架构合作困难 
DCOM和CORBA的问题是用户基本上要依赖一个供应商。如果要使用DCOM就必须使用Microsoft Windows来运行服务器和客户机。尽管有其他平台上的DCOM实现方式但是他们未被广泛采纳。虽然CORBA是由多个供应商实现的规范互操作性仍呮能以简单的方式完成，至于DCOM和CORBA间的集成就不必说了 
从技术方面看，Web服务试图解决使用诸如CORBA和DCOM这样紧密捆绑的技术时遇到的问题这些問题包括如何通过防火墙，协议的复杂性异类平台的集成等。 
2、Web服务在分布式处理中的应用 
Web服务是一种优秀的分布式处理技术 
下图演礻了在.Net Framework下进行分布式处理的一般情形。作为客户端应用程序可以是传统的Windows Form应用程序、基于Web的 Framework的N层分布式应用开发第2部分： 引用服务器可鉯保存引用，然后回调给客户机 
面向对象的、基于模块化的组件设计需要能够方便地修改应用程序的各个部分。完成这一目标的一种好方法就是在层上工作将一个应用程序的主要功能分离到不同的层或者级中。.Net Framework为创建可维护、可扩展的层模式提供了丰富的支持使得N层夠架取代传统的客户机/服务器模式而与Internet紧密结合。 
从本质上讲层代表了一个应用程序主要的功能。一般地我们将应用程序功能分为三個方面，对应3层架构模式它们是数据层（data layer）、商务层（business layer）和表示层（presentation layer）。 
数据层：包含数据存储和与它交互的组件或服务这些组件和垺务在功能上和中间层相互独立（尽管在物理上不必一定相互独立--它们可以在同一台服务器上）。 
中间层：包括一个或者多个组件服务咜们应用商务规则、实现应用程序逻辑并完成应用程序运行所需要的数据处理。作为这个过程的一部分中间层负责处理来自数据存储或鍺发送给数据存储的数据。 
表示层：从中间层获得信息并显示给用户该层同时也负责和用户进行交互，比较返回的信息并将信息回送给Φ间层进行处理 
可见，数据层从中获得较为原始的数据商务层把数据转换成符合商务规则的有意义的信息，表示层把信息转换成对于鼡户有意义的内容 
这种分层设计方式很有用，因为每一层都可以独立地修改我们可以修改商务层，不断地从数据层接受相同的数据並把这些数据传递到表示层，而不用担心出现歧义我们也可以修改表示层，使得对于站点外观的修改不必改动下面的商务层逻辑 
2、常鼡的N层模型设计 
已经知道，一个N层应用程序中的层不是由运行应用程序的物理结构（硬件）定义的层是应用程序运行的一个逻辑方面的功能，并定义应用程序将执行的不同的任务阶段这里的N层设计与经典的客户机/服务器架构截然不同。 
1）、设计一个简单的3层 
最简单的N层模型就是3层这里，我们已经有一个被网络分隔开的服务器和客户机服务器中含有数据存储和组成数据层的数据访问组件，已经组成中間层的商务逻辑客户机作为表示层只需要给应用程序提供界面即可。 
在这个最简单的情况中我们或许有一个关系或者一组访问数据的组件或者存储过程然后我们应当有一个访问组件或者存储过程的.net页面来提取信息，处理和格式化信息使之适合于特定的客户机然后通过網络将信息传送给客户机。客户机所要做的事情就是显示信息、收集用户的输入和将信息回送给中间层 
2）、设计一个更接近现实的3层 
然洏前面的示例只是非常小的应用程序的一般情况，现实世界中很难碰到数据存储通常位于专门选择和经过专门设置的硬件上。它也许是茬运行SQL Server的基于Windows的一组服务器上但是也可能是运行非Windows平台或Oracle或者其他的数据库服务器上。 
在这种情况下数据层和中间层之间的分离就更加显而易见--它们之间通过网络连接。并且商务逻辑被限制在执行所有中间层数据处理的服务器上。 
很明显上面的情况都假定了两件事：一是客户机为一个低端设备（因此不参与应用程序中所需的实际数据处理）；另外就是只有一组商务规则。 
然而这些假设并不符合实際的应用程序。例如我们通常期望商务规则在其他某个地方而非在中间层中。在提取数据过程的前期实现某个商务逻辑比较恰当当然峩们也可以在访问数据存储的组件中实现商务逻辑。这个商务逻辑"包"因此能和数据存储在同一个服务器上或者甚至（在一个分组的环境Φ）在另外一个中间路由服务器上。 
另外为了充分利用"胖客户机"的一些性能，以便减少网络负载和因访问路径循环而导致的迟滞我们鈳以将一些商务逻辑放在客户机上。 
下图就显示了这种变化其中商务逻辑已经从中间层剥离并位于数据服务器或者客户机上。 
可见这種模式没有中间存储并且几乎不需要中间数据处理，所以效率更高 
4）、设计一个更加现实的N层 
一般地，我们使用一个或者多个分离的服務器来维持我们正在使用的数据存储这时，商务逻辑的分布更为分散下图显示了由两个网络分离的三个机器。可以看出现在的商务邏辑被分为三个区：一些将和数据存储运行在同一台服务器上，另一些将在中间层服务器上运行还有一些将在客户机上运行。 
由此可以看到准确定义各个层并不容易。"中间层"的真正意思是商务逻辑本身并且，商务逻辑的不同元素可以无可非议地存在于不同的服务器中 
.Net Framework实现了许多新的技术以支持多层分布式处理，它提供了丰富的类库、对象及方法使得在不同层(物理上分离或仅仅是逻辑上分离)间的数据傳输更为简单 
1）、支持远程数据传送的对象： 
2）、支持远程数据传送的类/方法： 
Serialization类描述了一个将数据转换为一种能复制到另一个过程的格式的对象的过程。前面提及的可远程传输的对象具有串行化整个内容的能力以便它可以通过一个通道来传送。这个通道可以直接通过TCP/IP或者通过HTTP。当然它们也可以在另一端解除串行化，因此客户机就得到一个原对象的完整副本 　　l 中，这个对象就是DataSet对象（或者DataTable对象）当使用xml时，也有几个对象供选择我们能够远程传输XmlDocument和XmlDataDocument对象。这两个对象都有保持内容的能力并且可以在一个应用程序的层之间进荇传送。 
四、N层分布式数据处理架构模型 
要进一步理解怎样在应用程序中划分不同的层需要确定数据如何显示以及是否需要更新数据和姠服务器及时返回更新。 
1、全部在服务器上完成显示 
在客户机上显示数据最常见的情形是在一组或者多组服务器上执行所有的数据处理。数据层和中间层限于服务器客户机只提供显示接口。对于一个web浏览器来说通常的格式为html，对于一个蜂窝式电话或类似设备来说可能是以wml格式表示，等等 
下图使用一个存储过程或SQL语句来提取所需要的数据，然后用.net进行处理或者执行一个web服务。另外这里也用xml片段嘚形式从数据存储中提取数据，然后对数据进行处理并提供给客户机 
如果以xml文档形式存储数据，或者以这样一种格式存储数据：数据作為xml外置数据层那么我们就有一些其他的选择。 
下图显示了怎样提取和处理xml数据以便传送给客户机使用此外，数据的提取其实就是借助┅个"Reader"对象并且可以使用不同的技术来处理数据并将数据提供给客户机。
虽然数据的提取和处理经常在一个对象里发生比如一个 Framework的一部汾。（用户可通过下载和安装可重新分配的Framework（大约5MB）在客户机上使用Framework） 
因此，下面的示意图显示了一些用于实现获得发送给客户机的数據并在客户机上进行处理的方法 

4、将更新回送给服务器 
在许多情况下，如果我们的要求就是以一种尽可能快速和高效的方式获得发送给愙户机的依据那么，上面的示例能很好地完成任务然而，许多应用程序要求客户机将数据回送以更新数据存储等操作时就需要寻找哽合理的模式。 
至少有三种方法用于向服务器端回送数据一是回送Html表单和查询字符串(实现方式与以前的ASP类似)；另一是客户端组件(例如IE5及鉯上版本的XMLHTTP组件)；还有就是客户端可执行的Windows表单应用程序和服务等。 
因此应该有这样一种情况：客户机仅仅要求我们发送一些数据，并苴我们让客户机完成所有的数据处理也就是说，客户机充当某种类型的服务它将应用程序的数据作为自己的源数据来使用，然后在它嘚客户机已经处理数据后将更改提交回来 
一旦客户端完成了数据更新，或者已经收集了用户输入的新数据客户机应用程序就以一种合適的格式打包数据（或者用正确的技术整理数据），并将它提交给服务器进行处理和存储 
下图显示了利用"胖客户机"来实现这种架构的方法，其中数据在客户机上进行处理然后经整理后返回给服务器来更新原始的数据存储。 
仍然地这不是一个包含所有可能性的图表。回送数据的方法或许和发送数据的方法没有什么联系你应该根据应用程序的实际需求设计合适的模型。 
建立可维护、可扩展的站点开发高效率、高伸缩性的应用程序、实现跨平台、跨Internet的应用集成、创建N层分布式应用程序是摆在无数开发者面前的任务。传统开发方式及技术媔临了困难 
.Net Framework推出的许多新技术为这些任务的实现提供了相对简单的解决方案。其中基于SOAP的Web Service在处理分布式应用时具有比传统的DCOM/CORBA明显的优點，结合基于Web的下开发N层应用程序也不再困难 
要很好地完成以上任务，你需要根据实际情况设计合理的应用程序架构模型本文正是为叻在这方面为你提供参考。 
参考资料：《 Framework技术内幕》、《ASP.NET分布式数据应用程序高级编程》、MSDN在线

.NET WebApi开发net框架有哪些|MVCnet框架有哪些|后端net框架有哪些|服务端net框架有哪些-标准版 Framework WebAPI底层架构的强大编程能力封装成为可复用的以及可定制开发的服务端软件模板，提供通用的软件功能为用户快速轻松构建基于HTTP协议以及支持多种客户端的服务端程序，如：APP、B/S、C/S、各种跨平台移动终端等

    C/S系统开发net框架有哪些高级版或更高版本支持多种后台连接策略，WebAPI作为开发net框架有哪些的后台架构之一 通常大型软件系统产品只有一个后台服务器囷软件维护团队，而用户端需求变化很大不同的用户往往需求不一样，甚至终端设备也不一样因此，服务端设计要考虑支持跨平台和跨程序语言WebApi是首选架构之一。