ASP.NET教程之使用程序计划指南：从N层到 .NET
据说很厉害，甚至可以把C＃也干掉^_^，不过也很复杂，本来C＋＋已经够复杂的。有人甚至还提出把这个东东引进标准，我觉得基本上不可能的。程序|计划 择要：会商Microsoft.net的使用程序计划和所需的变动：查验从利用MicrosoftWindowsDNA构建N层使用程序中学到的布局常识，和怎样将这些常识使用到利用Microsoft.NET框架构建的使用程序，而且为利用XMLWebServices的使用程序供应系统布局方面的倡议。简介
现在，N层使用程序已成为构建企业软件的尺度。关于年夜多半人来讲，N层使用程序就是被分红多个自力的逻辑部分的使用程序。最多见的选择是分为三个部分：暗示、营业逻辑和数据，固然还大概存在其他的分别办法。N层使用程序最后是为懂得决与传统的客户端/服务器使用程序相干的成绩而呈现的，可是，跟着Web时期的到来，这一系统布局入手下手成为新开辟项目标支流。
MicrosoftWindows？DNA手艺已成为N层使用程序的十分乐成的基本。Microsoft.NET框架也为构建N层使用程序供应了坚固的平台。但是，。NET所带来的变更使布局计划职员应该从头思索他们在WindowsDNA范畴中所学的有关计划N层使用程序的某些常识。更主要的是，对内置于.NET框架的XMLWebservices的基础撑持同意开辟职员构建冲破传统N层办法的新使用程序。要懂得怎样更好地构建.NET使用程序的系统布局，您必要懂得这一新范畴中产生了哪些变更，和怎样充实使用这些变更。
本文将对这些成绩举行会商。起首回忆一下在利用WindowsDNA构建N层使用程序中学到的关头系统布局常识。然后，再按统一按次将这些常识使用到利用.NET框架构建使用程序的过程当中，从而对它们举行查验。最初一部分对利用XMLWebservices的使用程序的系统布局供应了一些倡议。
WindowsDNA情况
将使用程序分化成多个逻辑部分是很有效的。将一个年夜软件分红几个小的部分会更利于软件的构建、反复使用和修正，对顺应分歧的手艺或分歧的营业构造也很有匡助。同时，另有一些综合要素必要思索。固然模块化和反复利用性很无效，但它们大概会招致使用程序不克不及象利用其他办法那样平安、易办理和疾速。本节将回忆一些从利用WindowsDNA手艺构建N层使用程序的广泛履历中所取得的基础系统布局常识。
编写营业逻辑
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处置分层数据。
将数据传送到客户端
关于一切N层使用程序而言，将数据从两头层无效地挪动到客户端都是一个关头的环节。当利用DCOM与Windows客户端通讯时，WindowsDNA使用程序可使用ADO断开毗连的纪录集。当确保扫瞄器为InternetExplorer时，此选项也可用于扫瞄器客户端。而将数据发送就任意扫瞄器则对照坚苦。一种办法是显式地将数据转换为XML，然后将数据和一切需要的剧本代码发送到扫瞄器。
。net情况
。NET撑持传统的N层使用程序、WebServices使用程序和将两者的元素分离在一同的使用程序。本节起首先容.NET怎样影响N层使用程序，然后先容构建Webservices使用程序过程当中的几个次要的系统布局成绩。
将N层使用程序与.NET绑定在一同
上一节中先容的某些成绩一样合用于WindowsDNA使用程序和利用.NET框架构建的使用程序。比方，只要当满意后面所列的一个或多个前提时，才干利用COM+（在.NET框架中称为企业服务）。一样，将营业逻辑构建为存储历程在良多N层使用程序中都能够取得更好的功能。
同时，。NET框架中各处都是新手艺和现有手艺的新版本。这些加强功效为N层使用程序的优化系统布局带来了多种变更。本节将依照后面先容的分类，先容.NET框架是怎样改动系统布局计划职员在创立N层使用程序时所做的决意的。
编写营业逻辑
与在WindowsDNA中创立N层营业逻辑的三种可选办法（ASP页、COM组件和存储历程）分歧，。NET框架只供应了两种办法：程序集和存储历程。关于扫瞄器使用程序，可使用MicrosoftASP.NET.aspx页来创立程序集。与ASP分歧，在这类情形下完整利用ASP.NET编写营业逻辑一般是一个对照好的办法。
个中一个缘故原由就是ASP.NET的内含代码选项。在传统的ASP页中，以一种可保护的体例夹杂营业代码和暗示代码并非一件简单的事，而.aspx页利用内含代码可以完整将这两种代码分隔。WindowsDNA使用程序大概必要同时利用ASP页和COM工具才干完成可保护性，而利用.NET框架构建的使用程序则只需利用ASP.NET.别的，。aspx页中包括的营业逻辑能够用任何基于.NET的言语编写，而不但限于传统ASP页所撑持的复杂的剧本言语。并且，ASP.NET是编译页面而不是注释页面，因而ASP.NET使用程序速率能够十分快。固然利用WindowsDNA构建的使用程序可使用ASP页和COM工具来到达充足高的功能，但.NET只需利用ASP.NET即可构建具有一样优秀功能的使用程序。最初，营业逻辑利用ASP.NET缓存来削减对包括经常使用数据的数据库的会见，如许能够年夜年夜进步功能。
可是，必要指出的是，关于包括在.aspx页中的代码，即便是利用内含代码，其反复利用也比尺度的程序集坚苦。比方，从Windows窗体客户端会见.aspx页中的代码会碰到良多成绩。
构建客户端
利用.NET框架可削减对Windows客户真个需求，一般只必要一个扫瞄器客户端便可。个中一个缘故原由在于，ASP.NETWeb控件同意构建和/或购置可反复利用的扫瞄器图形用户界面（GUI）元素，从而可以更便利地构建更有效的扫瞄器客户端。并且能够将基于.NET框架的组件下载到InternetExplorer客户端，然后利用部分信托来运转这些组件（而不利用ActiveX控件所请求的满是全非信托形式），这有助于构建更好的用户界面。
办理扫瞄器使用程序中的形态
因为ASPSession工具被绑定到一台呆板上，因而它并未发扬出应有的感化，而利用.NET框架就制止了这类限定。与ASP分歧，ASP.NETSession工具能够被两台或多台呆板共享，从而可使用Session工具来保护负载均衡的Web服务器范畴中的形态，使其加倍有效。并且，因为Session工具的内容能够选择存储在SQLServer数据库中，这类机制可用于呈现妨碍时必需一向坚持每一个客户真个形态的使用程序中。
影响ASP.NET使用程序系统布局的另外一个主要变动在于，数据集能够存储在Session和Application工具中而无需包括线程，这一点与ASP分歧。也就是说，在WindowsDNA中严厉划定的不克不及将纪录集存储在这些工具中的划定规矩不合用于.NET框架中的数据集。这就使得查询了局的存储加倍复杂也加倍天然。
散布式通讯
与WindowsDNA比拟，。NET框架为使用程序的散布式部件之间的通讯供应了更多选择，包含：
●。NETRemoting，供应TCP通道和HTTP通道；
●ASP.NET撑持在.asmx页中完成的、可经由过程SOAP挪用的XMLWebservices；
●与远程COM工具通讯所需的DCOM.
选项越多，意味着系统布局的选择也越多，这也意味着做选择时有更多必要思索的要素。利用.NET框架创立散布式使用程序时要懂得的系统布局成绩包含：
●间接与远程COM+工具举行通讯请求利用DCOM，而不克不及利用.NETRemoting.因为DCOM的创建和利用都相称庞大，因而应只管制止这类通讯。在某些情形下，有需要经由过程托管代码处置现有的COM+工具，只管如许做所请求的COM互操纵性会下降功能。
●。NETRemotingTCP通道没有供应内置的平安性。与DCOM分歧，它不供应严厉的身份考证、数据完全性或数据保密服务。但它并不是一无可取，TCP通道比DCOM更简单设置。
●DCOM不克不及很好地与防火墙共同利用，。NETRemotingHTTP通道与之分歧，它是专门为在Internet长进行无效通讯而计划的。并且，因为可使用SSL，此选项可以为数据供应平安的路径。一般，关于Intranet通讯而言，TCP通道是较好的选择；而关于Internet通讯，则更合适利用HTTP通道或ASP.NETSOAP撑持。
●。NETRemotingHTTP通道和用于XMLWebservices的ASP.NET撑持都能完成SOAP.但这两种完成却一模一样，各有其特定的目标。。NETRemoting注意坚持大众言语运转时切实其实切语义，因而当远程体系也运转.NET框架时，它是最好选择。ASP.NET则注意供应相对尺度的XMLWebservices，因而当远程体系是基于.NET的平台或任何其他平台时，它是最好选择。并且ASP.NET比.NETRemotingHTTP通道的速率快。但HTTP通道也有长处，它同意经由过程援用和真实的异步回调来传送参数，这是ASP.NET中的SOAP撑持所不具有的功效。
会见存储数据
ADO可以便利地构建重型客户端，但客户真个伸缩性较差，ADO.NET与ADO分歧，它更合用于构建轻型客户端。ADO.NET客户端利用仅向前的只读游标读取数据。它不撑持有形态的服务器端游标，因而其编程形式勉励短工夫的毗连。间接读取和处置数据的客户端可使用ADO.NET的DataReader工具，它不为前往的数据供应缓存。大概，能够将数据读进DataSet工具中，将其作为从SQL查询和其他源中前往的数据的缓存。可是，与ADO纪录集分歧，数据集不克不及显式地保护与数据库的开放毗连。
如后面所述，ADO天生的重型办法还存在一些其他成绩。这些成绩能够在ADO.NET中办理，以下所示：
●关于将数据存储在数据集并请求会见由其他用户或使用程序所做的变动的ADO.NET客户端，必要包括显式代码才干举行这些变动。该代码一般还必要为每一个所举行的反省翻开一个数据库毗连。
●只管ADO.NET其实不间接撑持守旧式锁定，但经由过程利用ADO.NET事件或在存储过程当中完成所需的功效，客户端仍旧能够取得一样的效果。
●与ADO分歧，ADO.NET不同意将部分查询了局保存在数据库中（可使用服务器端游标从中举行会见）。固然ADO.NET的确比ADO检索的元数据要少，但使用程序仍应计划为可以将一切的查询了局从数据库传送到ADO.NET客户端。
ADO.NET中影响系统布局选择的另外一项变动是其对处置分层数据（出格是XML文档）的撑持加强了。将ADO.NET数据集转换成XML十分复杂，就象会见SQLServer2000的XML功效一样。因而，在WindowsDNA中大概被强迫装进干系模子中的分层数据如今能够以其原始情势供应会见。
将数据传送到客户端
将数占有效地传送到客户端关于在.net框架上构建的N层使用程序和利用WindowsDNA构建的使用程序一样主要。一项主要的变动在于，ADO.NET数据集可主动序列化成XML，从而使得各层之间的数据传送加倍复杂。固然在WindowsDNA中也能够利用这类办法，但.NET使经由过程XML的信息互换变得加倍复杂、间接。
XMLWebServices系统布局
在构建散布式使用程序的过程当中，能够经由过程多种办法来利用XMLWebservices的SOAP、WebServices申明言语（WSDL）和其他手艺。比方：
●利用SOAP而不是仅仅利用HTTP毗连到N层使用程序的Web客户端。毗连创建后，该客户端能够是可以举行SOAP挪用的恣意设备。以后，客户端能够为其用户供应更多的功效，由于它可以间接挪用远程服务器中的办法。
●将多是在基于.NET框架的平台上构建的N层使用程序与在其他平台（比方Java使用程序服务器）上构建的另外一个使用程序毗连起来。
●毗连两个年夜型使用程序，大概毗连一个企业资本计划（ERP）体系与另外一个ERP体系或任何其他使用程序。正如这些示例所示，XMLWebservices不单单合用于N层使用程序，其使用局限非常宽广。
不论怎样利用，XMLWebservices城市带来很多新的系统布局成绩。XMLWebservices与N层使用程序一般利用的更加传统的两头件手艺之间的最次要的不同也许在于，XMLWebservices供应的是“松懈耦合”。遗憾的是，这个词关于分歧的用户有着分歧的寄义。在本文中，它是指具有以下特性的通讯使用程序：
●使用程序在很年夜水平上互相自力，而且一般由分歧的构造把持。
●其实不完整牢靠。不克不及包管每一个通讯使用程序在一切工夫都可用。
●其交互操纵能够是同步的，也能够是异步的。Webservices客户端大概堵塞对某个哀求的呼应的守候，也能够在收回哀求后往做其他事，稍后再来反省呼应。
●这些基础特性为利用XMLWebservices的使用程序供应了良多系统布局方面的准绳。固然有些成绩大概会在今后的事情中失掉办理，如Microsoft的GlobalXMLWebServicesArchitecture（GXA）specifications（英文），可是今朝，创立无效的XMLWebservices使用程序的用户必需要懂得这些成绩。个中包含：
●平安性大概会对照庞大。事后计划端对端身份考证和无效受权非常主要。端对真个数据完全性和数据保密性对某些使用程序也很主要。大概有需要在分歧的平安机制之间举行映照，固然最好只管制止这类情形。互操纵性大概会成为成绩。因为标准还绝对不成熟，分歧供给商的SOAP完成还不克不及一直很好地合作。
●修正现有使用程序以即可以经由过程XMLWebservices举行会见时，大概会呈现成绩。当把从未盘算要在一同利用的程序毗连在一同时，总会呈现速率、可伸缩性和平安性等成绩。现有使用程序一般不是作为服务器而构建的，因而处置一些很小的哀求就会容易弄垮它们。削减哀求数目，而增添每一个哀求中包括的数据大概会进步使用程序的功能。别的，现有使用程序一般不克不及处置意料以外的负载，比方向Internet公然软件时大概发生的负载。假如大概，利用某种列队机制以在哀求被呼应之前将哀求存储起来，这大概会有所匡助。
●调治妨碍十分主要。特别是只必要一次语义的哀求，一般必要分外当心。比方，哀求大概会超时，从而触发重试，但本来的哀求大概只是由于某种缘故原由被提早罢了。假如针对单个挪用实行两次远程Webservice会呈现成绩，则必需创立某种机制来办理这个成绩。
●不成能供应依附于散布式锁定（超过构造界限坚持）的端对端事件。年夜多半构造不同意“外来”使用程序锁定命据，因而不成能完成两阶段提交款式的事件。而只能思索为任何须要的回滚利用抵偿事件。
●因为收到的数据大概超过使用程序和构造界限，Webservices通讯的每端大概都必要细心反省该数据。固然使用程序的创立者大概非常信托由他们本人的使用程序的其他部分所天生的数据的正确性，但他们不克不及对其他使用程序抱以一样的信托。收到的信息乃至大概包括歹意代码，因而必需细心反省。
●SOAP及其照顾的XML界说的数据十分多。在一个挪用中传送太多半据大概会弄垮低带宽的收集。反过去，在一个挪用中传送的数据太少又会弄垮处置这些哀求的使用程序。只管这很坚苦，但找到准确的均衡点仍是很主要的。
小结
系统布局是关头。为使用程序（特别是散布于多个体系的使用程序）选择准确的布局是相当主要的。假如选择了毛病的系统布局，不论开辟职员何等优异，一般都没法在完成过程当中修复。毛病的决意会招致功能下降、平安性下降和使用程序必要更新时可用的选项较少。
WindowsDNA为N层使用程序奠基了一个坚固的基本，Windows开辟职员能够依据他们从DNA范畴所学到的常识来构建使用程序，把个中的年夜部分使用到新的.NET情况中。不外，懂得本文所倡议的变动将有助于创立更快、更平安、功效更强的使用程序。关于N层使用程序和接纳Webservices新手艺的使用程序来讲，。NET可供应的功效良多。
学习asp.net两个月有余了，除了对html、web控件比较熟悉（应该是说都能理解和接受）之外，竟不知道自己还会什么。看了两本书：《精通asp.net网络编程》（人民邮电出版社）、《asp.net实用案例教程》（清华大学出版社）。 ASP.net的服务器，要求安装一个.net环境，当然我这里指的是windows系统，顺便点一下，.net只能放在windows环境里来运行。Asp.net1.1的就装Framework1.1，Asp.net2.0的就装Framework2.0。 同时也感谢博客园给我们这个平台，也感谢博客园的编辑们做成专题引来这么多高人指点。 那么，ASP.Net有哪些改进呢？ 比如封装性、继承性、多态性等等，这就解决了刚才谈到的ASP的那些弱点。封装性使得代码逻辑清晰，易于管理，并且应用到ASP.Net上就可以使业务逻辑和Html页面分离，这样无论页面原型如何改变。 碰到复杂点的问题都不知道能不能解决，现在有点实力的公司都选择自已在开源的基础上做开发。但没听说过有人在IIS上做改进的,windows、sqlserver集群方面的应用也很少见。 PHP的源代码完全公开，在OpenSource意识抬头的今天，它更是这方面的中流砥柱。不断地有新的函数库加入，以及不停地更新，使得PHP无论在UNIX或是Win32的平台上都可以有更多新的功能。它提供丰富的函数，使得在程式设计方面有着更好的资源。目前PHP的最新版本为4.1.1，它可以在Win32以及UNIX/Linux等几乎所有的平台上良好工作。PHP在4.0版后使用了全新的Zend引擎，其在最佳化之后的效率，比较传统CGI或者ASP等技术有了更好的表现。 PHP的源代码完全公开，在OpenSource意识抬头的今天，它更是这方面的中流砥柱。不断地有新的函数库加入，以及不停地更新，使得PHP无论在UNIX或是Win32的平台上都可以有更多新的功能。它提供丰富的函数，使得在程式设计方面有着更好的资源。目前PHP的最新版本为4.1.1，它可以在Win32以及UNIX/Linux等几乎所有的平台上良好工作。PHP在4.0版后使用了全新的Zend引擎，其在最佳化之后的效率，比较传统CGI或者ASP等技术有了更好的表现。 比如封装性、继承性、多态性等等，这就解决了刚才谈到的ASP的那些弱点。封装性使得代码逻辑清晰，易于管理，并且应用到ASP.Net上就可以使业务逻辑和Html页面分离，这样无论页面原型如何改变。
页:
[1]