您的位置：首页 > 其它

Factory Pattern在.Net Remoting Architecture中的实现

2005-08-22 15:48 267 查看

FactoryPattern在.NetRemotingArchitecture中的实现

混合法

混合法需要使用RecordingsFactorySAO，它提供了创建RecordingsManagerCAO的方法。（如果您不熟悉SAO示例，请参阅"使用服务器激活对象通过.NETRemoting实现Broker"。）下面的类图表描述了总体解决方案。图1:混合法的结构这种实现使用了SAO示例中所描述的共享接口法。IRecordingsManager和IRecordingsFactory这两个接口位于客户端和服务器所共享的程序集中。IRecordingsFactory有一个Create方法，它可以返回一个对象来实现IRecordingsManager接口。这是AbstractFactory[Gamma95]模式的一个例子。因为客户端只依靠接口，所以无需传送服务器代码。当客户端需要IRecordingsManager对象时，它调用IRecordingsFactory实例的Create方法。这样，客户端就可以控制IRecordingsManager对象的生存期，而无需实现该对象。共享程序集中的两个接口是：IRecordingsManager.cs以下示例显示了IRecordingsManager接口：

usingSystem;
usingSystem.Data;
publicinterfaceIRecordingsManager
{
DataSetGetRecordings();
}

IRecordingsFactory.cs以下示例显示了IRecordingsFactory接口：

usingSystem;
publicinterfaceIRecordingsFactory
{
IRecordingsManagerCreate();
}

这些对象的服务器实现（RecordingsFactory和RecordingsManager）非常简单，并且包含在它们自己的、名为Server的程序集中。RecordingsFactory.cs该类扩展了MarshalByRefObject，并实现了IRecordingsFactory接口：

usingSystem;
publicclassRecordingsFactory:MarshalByRefObject,IRecordingsFactory
{
publicIRecordingsManagerCreate()
{
returnnewRecordingsManager();
}
}

RecordingsFactory对象是服务器激活对象。该实现只是对RecordingsManager类型调用new。该RecordingsManager对象是在服务器上创建的，并且，不是作为RecordingsManager对象、而是作为IRecordingsManager接口返回的。利用这种机制，客户端就可以依赖于接口而不是实现。RecordingsManager.csRecordingsManager类所需要的唯一更改是，它现在实现的是IRecordingsManager接口。

usingSystem;
usingSystem.Reflection;
usingSystem.Data;
usingSystem.Data.SqlClient;
publicclassRecordingsManager:MarshalByRefObject,IRecordingsManager
{
publicDataSetGetRecordings()
{
Console.WriteLine("Assembly:{0}-fillingarequest",
Assembly.GetEntryAssembly().GetName().Name);
StringselectCmd="select*fromRecording";
SqlConnectionmyConnection=newSqlConnection(
"server=(local);database=recordings;Trusted_Connection=yes");
SqlDataAdaptermyCommand=
newSqlDataAdapter(selectCmd,myConnection);
DataSetds=newDataSet();
myCommand.Fill(ds,"Recording");
returnds;
}
}

HttpServer.cs混合法中的服务器初始化代码用于为服务器激活的RecordingsFactory对象配置远程处理框架。激活方式与所使用的通道和协议无关，因此与以前一样（端口8100上的HTTP协议）。

usingSystem;
usingSystem.Runtime.Remoting;
usingSystem.Runtime.Remoting.Channels;
usingSystem.Runtime.Remoting.Channels.Http;
publicclassHttpServer
{
staticvoidMain(string[]args)
{
HttpChannelchannel=newHttpChannel(8100);
ChannelServices.RegisterChannel(channel);
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(RecordingsFactory),
"RecordingsFactory.soap",
WellKnownObjectMode.Singleton);
Console.ReadLine();
}
}

在该代码中，RecordingsFactory类型与URLhttp://localhost:8100/RecordingsFactory.soap相关联。HttpClient.cs客户端代码显示了这种方式的混合性质。首先使用Activator.GetObject方法从服务器检索IRecordingsFactory对象。然后，使用这个服务器激活对象来调用Create方法，以便实例化一个IRecordingsManager对象。这个新实例化的对象是在服务器上创建的，但它是一个远程对象。

usingSystem;
usingSystem.Data;
usingSystem.Runtime.Remoting;
usingSystem.Runtime.Remoting.Channels;
usingSystem.Runtime.Remoting.Channels.Http;
publicclassHttpClient
{
[STAThread]
staticvoidMain(string[]args)
{
HttpChannelchannel=newHttpChannel();
ChannelServices.RegisterChannel(channel);
IRecordingsFactoryfactory=(IRecordingsFactory)
Activator.GetObject(typeof(IRecordingsFactory),
"http://localhost:8100/RecordingsFactory.soap");
Console.WriteLine("Client.main():Factoryacquired");
IRecordingsManagermgr=factory.Create();
DataSetds=mgr.GetRecordings();
Console.WriteLine("RecordingsCount:{0}",
ds.Tables["recording"].Rows.Count);
}
}

23:31

固定链接|评论(0)|引用通告(0)|记录它|.NETFRAMEWORK

固定链接

关闭

http://spaces.msn.com/members/glasscao/Blog/cns!1p-TWH5oRY7QQCLjMt-Lir6g!175.entry

远程对象的激活方式

2、远程对象的激活方式在访问远程类型的一个对象实例之前，必须通过一个名为Activation的进程创建它并进行初始化。这种客户端通过通道来创建远程对象，称为对象的激活。在Remoting中，远程对象的激活分为两大类：服务器端激活和客户端激活。(1)服务器端激活，又叫做WellKnow方式，很多又翻译为知名对象。为什么称为知名对象激活模式呢？是因为服务器应用程序在激活对象实例之前会在一个众所周知的统一资源标识符(URI)上来发布这个类型。然后该服务器进程会为此类型配置一个WellKnown对象，并根据指定的端口或地址来发布对象。.NetRemoting把服务器端激活又分为SingleTon模式和SingleCall模式两种。SingleTon模式：此为有状态模式。如果设置为SingleTon激活方式，则Remoting将为所有客户端建立同一个对象实例。当对象处于活动状态时，SingleTon实例会处理所有后来的客户端访问请求，而不管它们是同一个客户端，还是其他客户端。SingleTon实例将在方法调用中一直维持其状态。举例来说，如果一个远程对象有一个累加方法（i=0；++i），被多个客户端（例如两个）调用。如果设置为SingleTon方式，则第一个客户获得值为1，第二个客户获得值为2，因为他们获得的对象实例是相同的。如果熟悉Asp.Net的状态管理，我们可以认为它是一种Application状态。SingleCall模式：SingleCall是一种无状态模式。一旦设置为SingleCall模式，则当客户端调用远程对象的方法时，Remoting会为每一个客户端建立一个远程对象实例，至于对象实例的销毁则是由GC自动管理的。同上一个例子而言，则访问远程对象的两个客户获得的都是1。我们仍然可以借鉴Asp.Net的状态管理，认为它是一种Session状态。(2)客户端激活。与WellKnown模式不同，Remoting在激活每个对象实例的时候，会给每个客户端激活的类型指派一个URI。客户端激活模式一旦获得客户端的请求，将为每一个客户端都建立一个实例引用。SingleCall模式和客户端激活模式是有区别的：首先，对象实例创建的时间不一样。客户端激活方式是客户一旦发出调用的请求，就实例化；而SingleCall则是要等到调用对象方法时再创建。其次，SingleCall模式激活的对象是无状态的，对象生命期的管理是由GC管理的，而客户端激活的对象则有状态，其生命周期可自定义。其三，两种激活模式在服务器端和客户端实现的方法不一样。尤其是在客户端，SingleCall模式是由GetObject()来激活，它调用对象默认的构造函数。而客户端激活模式，则通过CreateInstance()来激活，它可以传递参数，所以可以调用自定义的构造函数来创建实例。(1)SingleTon模式对于WellKnown对象，可以通过静态方法RemotingConfiguration.RegisterWellKnownServiceType()来实现：RemotingConfiguration.RegisterWellKnownServiceType(typeof(ServerRemoteObject.ServerObject),"ServiceMessage",WellKnownObjectMode.SingleTon);(2)SingleCall模式注册对象的方法基本上和SingleTon模式相同，只需要将枚举参数WellKnownObjectMode改为SingleCall就可以了。RemotingConfiguration.RegisterWellKnownServiceType(typeof(ServerRemoteObject.ServerObject),"ServiceMessage",WellKnownObjectMode.SingleCall);(3)客户端激活模式对于客户端激活模式，使用的方法又有不同，但区别不大，看了代码就一目了然。RemotingConfiguration.ApplicationName="ServiceMessage";RemotingConfiguration.RegisterActivatedServiceType(typeof(ServerRemoteObject.ServerObject));为什么要在注册对象方法前设置ApplicationName属性呢？其实这个属性就是该对象的URI。对于WellKnown模式，URI是放在RegisterWellKnownServiceType()方法的参数中，当然也可以拿出来专门对ApplicationName属性赋值。而RegisterActivatedServiceType()方法的重载中，没有ApplicationName的参数，所以必须分开。2、客户端获得远程对象。与服务器端相同，不同的激活模式决定了客户端的实现方式也将不同。不过这个区别仅仅是WellKnown激活模式和客户端激活模式之间的区别，而对于SingleTon和SingleCall模式，客户端的实现完全相同。(1)WellKnown激活模式要获得服务器端的知名远程对象，可通过Activator进程的GetObject()方法来获得：ServerRemoteObject.ServerObjectserverObj=(ServerRemoteObject.ServerObject)Activator.GetObject(typeof(ServerRemoteObject.ServerObject),"tcp://localhost:8080/ServiceMessage");首先以WellKnown模式激活，客户端获得对象的方法是使用GetObject（）。其中参数第一个是远程对象的类型。第二个参数就是服务器端的uri。如果是http通道，自然是用http://localhost:8080/ServiceMessage了。因为我是用本地机，所以这里是localhost，你可以用具体的服务器IP地址来代替它。端口必须和服务器端的端口一致。后面则是服务器定义的远程对象服务名，即ApplicationName属性的内容。(2)客户端激活模式如前所述，WellKnown模式在客户端创建对象时，只能调用默认的构造函数，上面的代码就说明了这一点，因为GetObject()方法不能传递构造函数的参数。而客户端激活模式则可以通过自定义的构造函数来创建远程对象。客户端激活模式有两种方法：1)调用RemotingConfiguration的静态方法RegisterActivatedClientType()。这个方法返回值为Void，它只是将远程对象注册在客户端而已。具体的实例化还需要调用对象类的构造函数。RemotingConfiguration.RegisterActivatedClientType(typeof(ServerRemoteObject.ServerObject),"tcp://localhost:8080/ServiceMessage");ServerRemoteObject.ServerObjectserverObj=newServerRemoteObject.ServerObject();2)调用进程Activator的CreateInstance()方法。这个方法将创建方法参数指定类型的类对象。它与前面的GetObject()不同的是，它要在客户端调用构造函数，而GetObject()只是获得对象，而创建实例是在服务器端完成的。CreateInstance()方法有很多个重载，我着重说一下其中常用的两个。a、publicstaticobjectCreateInstance(Typetype,object[]args,object[]activationAttributes);参数说明：type：要创建的对象的类型。args：与要调用构造函数的参数数量、顺序和类型匹配的参数数组。如果args为空数组或空引用（VisualBasic中为Nothing），则调用不带任何参数的构造函数（默认构造函数）。activationAttributes：包含一个或多个可以参与激活的属性的数组。这里的参数args是一个object[]数组类型。它可以传递要创建对象的构造函数中的参数。从这里其实可以得到一个结论：WellKnown激活模式所传递的远程对象类，只能使用默认的构造函数；而Activated模式则可以用户自定义构造函数。activationAttributes参数在这个方法中通常用来传递服务器的url。假设我们的远程对象类ServerObject有个构造函数：ServerObject(stringpName,stringpSex,intpAge){name=pName;sex=pSex;age=pAge;}那么实现的代码是：object[]attrs={newUrlAttribute("tcp://localhost:8080/ServiceMessage")};object[]objs=newobject[3];objs[0]="wayfarer";objs[1]="male";objs[2]=28;ServerRemoteObject.ServerObject=Activator.CreateInstance(typeof(ServerRemoteObject.ServerObject),objs,attrs);可以看到，objs[]数组传递的就是构造函数的参数。b、publicstaticObjectHandleCreateInstance(stringassemblyName,stringtypeName,object[]activationAttribute);参数说明：assemblyName：将在其中查找名为typeName的类型的程序集的名称。如果assemblyName为空引用（VisualBasic中为Nothing），则搜索正在执行的程序集。typeName：首选类型的名称。activationAttributes：包含一个或多个可以参与激活的属性的数组。参数说明一目了然。注意这个方法返回值为ObjectHandle类型，因此代码与前不同：object[]attrs={newUrlAttribute("tcp://localhost:8080/EchoMessage")};ObjectHandlehandle=Activator.CreateInstance("ServerRemoteObject","ServerRemoteObject.ServerObject",attrs);ServerRemoteObject.ServerObjectobj=(ServerRemoteObject.ServerObject)handle.Unwrap();这个方法实际上是调用的默认构造函数。ObjectHandle.Unwrap()方法是返回被包装的对象。说明：要使用UrlAttribute，还需要在命名空间中添加：usingSystem.Runtime.Remoting.Activation;

10:39

固定链接|评论(0)|引用通告(0)|记录它|.NETFRAMEWORK

固定链接

关闭

http://spaces.msn.com/members/glasscao/Blog/cns!1p-TWH5oRY7QQCLjMt-Lir6g!174.entry

2005-7-26

NETWebservicesvs.remoting:Whichonewillworkbestforyourapp?

MicrosofthasmadeatremendousamountofnoiseaboutbuildingapplicationswithWebservices,andits.NETFrameworksimplifiesthetaskofworkingwiththem.ButwhileWebservicesrepresentagreatwaytobuildapplications,theyareideallysuitedforclientsoutsidethefirewallcallingcomponentsonyourserverovertheInternet.

Ifbothyourclientsandcomponentsareinsidethefirewall,Webservicesmayworkfine;however,allofyourdatatravelsthroughaWebserver,whichcanslowperformance.Tospeedthingsup,Microsoftprovidesabinarymechanismcalledremoting.Let'stakealookathowremotingworks,andI'llsharesomecodeexamplesthatshowyouhowtosetitupinasampleWebservice.HowWebservicesworkwith.NETForabriefexplanationonhowWebserviceswork,andspecificallyhowtheyworkin.NET,checkoutthissidebar..NETremotingWhileWebservicesarearguablythebestwayforclientsoutsideofyourorganizationtoaccesscomponents,whataboutcomponentswithinyourorganization?ManycompaniesarebuildingWebservicesandusingtheminternally.Thereisnothingwrongwiththisapproach,butitdoesn'tprovidethebestperformance.Ifcomponentsarecreatedin.NETandtheclientapplicationsare.NET,youcanplacecomponentsonsharedserversandaccessthemviaremoting.Remotingisthe.NETtechnologythatreplacesDCOMallowingyoutocommunicatebetweenaclientapplicationandcomponentsinabinaryformat.Asaresult,remotablecomponentsarefasterthanWebservices.However,creatingremotablecomponentsismoredifficultbecauseyoumustaddadditionalcodetoyourcomponents.Thiscodeisn'tmuchmorecomplicatedthanitsWebservicecounterpart,butyoucannotdirectlyinstantiatearemotecomponent.Instead,youmustcreateahostapplicationthatinstantiatesthecomponentandlistensforrequests.ThegoodnewsisthatthishostcanbeaWindowsservice,aWindowsapplication,aconsoleapplication,oranythingthatcanrunandholdtheobjectopen.Notonlydoyouhavetocreateahostapplication,youmustalsomakeseveraldecisionsabouttheremotableobject,suchaswhichchanneltouse..NETsupportsbothHTTPandTCPchannels.TheHTTPchannelactuallyusestheSOAPprotocoltotransportmessagestoandfromremotableobjects;thismeansallmessagesareserializedtoXML.TheTCPchannelusesabinarystreamtotransportthemessages.Next,youmustchoosebetweentwoactivationmodes:SingletonandSingleCall.Singletontypeshaveonlyoneinstanceofanobjectatanytime.Allclientrequestsareservicedbythatsingleinstance.Thisallowsyouto"share"databetweenrequestsor,morelikely,maintainstatebetweenrequests.SingleCalltypes,ontheotherhand,createanewinstanceoftheobjectforeachclientrequest.SingleCallobjectsaremorelikeWebservicesbecausetheyarestatelessandarecreatedanddestroyedforeachrequest..NETisarchitectedinsuchawaythatremotablecomponentscanchangechannelswithoutbeingrecompiled.YoucanplacethechannelinformationinaconfigurationfileandchangefromTCPtoHTTPorviceversawithoutrecompilingtheapplication.Similarly,youcanchangeaconfigurationfilefortheclienttomatchthechannelthatthehostisusing.QuickcodecomparisonsToseesomequickexamplesofaWebserviceandaremotableobjectwithhost,I'llusetheexampleIusedinapreviousarticleinwhichIcreatedasimpleWebservice.TheentirecodefortheWebservicefollows:<%@WebServiceLanguage="VB"Class="ConvertMoney"%>ImportsSystem.Web.Services<WebService()>PublicClassConvertMoneyInheritsWebService<WebMethod()>PublicFunction_PoundsToDollars(BritishPoundsAsDouble)AsDoubleReturnBritishPounds*1.44EndFunctionEndClassHereisthecodetoimplementthesamethingwitharemotablecomponent:PublicClassConvertMoneyInheritsSystem.MarshalByRefObjectPublicFunction_PoundsToDollars(ByValBritishPoundsAsDouble)AsDoubleReturnBritishPounds*1.44EndFunctionEndClassThecomponentlookssimpler.Infact,theonlydifferenceisthatitinheritsfromSystem.MarshalByRefObject.Butremember,youneedtobuildahostapplicationthatinstantiatestheobjectandlistensforrequests.Thecodeforthehostobjectcouldlooklikethis:ImportsSystem.Runtime.RemotingImportsSystem.Runtime.Remoting.ChannelsImportsSystem.Runtime.Remoting.Channels.TcpImportsRemoteConvertMoneyModuleModule1SubMain()DimtcpChannelAsNewTcpChannel(7777)ChannelServices.RegisterChannel(tcpChannel)DimChangeMoneyAsNewConvertMoneyRemotingServices.Marshal(ChangeMoney,"ConvertMoney")Console.ReadLine()EndSubEndModuleInthiscase,thehostapplicationisaconsoleapplication.Youstarttheapplicationanditlaunchesaconsoleapplicationandcreatestheobject.Theconsoleapplicationrunsuntilsomeonepressesthe[Enter]key,andtheobjectisavailableuntilneeded.Asyoucansee,theamountofworkrequiredtocreatetheremotablecomponentismorethantheWebservice.MakethechoiceThereisnoabsoluteanswertowhetheryoushouldchooseWebservicesorremotinginmostcases.Ifyourentiredistributedapplicationisinsideyourorganizationfirewallandperformanceiscritical,remotingviatheTCPchannelisthebestchoice.Iftheentireapplicationisinsidethefirewallandperformanceisn'tascritical,orifyouwanttokeepthingsassimpleaspossible,Webservicesisabetterchoice.But,ifyouneedtoallowaccesstoclientsotherthan.NET,you'llneedtouseWebservicesregardlessofwhetherornottheclientisinsideoroutsidethefirewall.Intheend,thechoiceislefttothedeveloper,soyou'llneedthoroughknowledgeofbothtechnologiestomakeaproperdecision.

0:34

固定链接|评论(0)|引用通告(0)|记录它|.NETFRAMEWORK

固定链接

关闭

http://spaces.msn.com/members/glasscao/Blog/cns!1p-TWH5oRY7QQCLjMt-Lir6g!173.entry

Webservicesin.NET

Webservices,calledXMLWebservicesbyMicrosoft,arethecomponentsthatareinstantiatedviaHTTP.Dataispassedto,andreceivedfrom,WebservicesusingHTTPandSOAP,whichiscleartextandbaseduponXML.ThankstoWebservices,passingdatabetweendifferentoperatingsystemsondifferentplatformshasbeensimplified.WebservicesuseHTTPtocommunicate,andthisrequiresaWebserver.RequestsmustbeturnedintoSOAPmessagesthataresenttotheWebserver.There,theyareprocessed,theobjectisinstantiated,themethodisexecuted,andthedataisplacedinanXMLformattobereturnedtotheclient.TheclientapplicationprocessestheXMLasnecessary.Giventhisscenario,itisnogreatsurprisethatWebservicesareslowwhencomparedtodirectbinaryaccessofobjects.WithoutWebservices,datadoesnothavetobeserializedtoXMLanddeserializedontheclient.RequestsandreturnsdonothavetoflowthroughaWebserver.Ofcourse,Webservicesdoofferadvantages.First,theycanbecalledbyalmostanyclient.Theclientdoesnothavetobea.NETapplication.Infact,theclientmachinedoesnotneedtoberunningaWindowsoperatingsystem.Second,becauseWebservicesuseSOAP,thedataflowsacrossfirewallseasily;alldataispassedasXML.Finally,asfaras.NETisconcerned,the.NETFrameworkmakesitincrediblyeasytocreateWebservices,andyoucandosowithjustafewlinesofcode.

0:04

固定链接|评论(0)|引用通告(0)|记录它|.NETFRAMEWORK

固定链接

关闭

http://spaces.msn.com/members/glasscao/Blog/cns!1p-TWH5oRY7QQCLjMt-Lir6g!172.entry

2005-7-25

BuildingDistributedApps?UseXMLWebServices,NotRemoting(Mostly)

IfyouhavebeenwonderingwhethertouseXMLWebservicesor.NETRemoting,here'sasimpleanswer:UseXMLWebservicesmostofthetime.XMLWebservicesarethesameasmarshal-by-value.NETRemoting,butusingthemismucheasierthanusingRemotingfromscratch.Marshal-by-valueremoting(XMLWebservices)meansthatyougetXML-serializeddatafromyourremoteserver.Sometimes,youmayneeddynamiceventbehaviororyoumaynotwanttomovemassiveamountsofdataandneedalittlemorecontrol.Inthisinstance,youpeelbacktheXMLWebserviceslayerandstartbuildingdirectlyontopof.NETRemotingwithmarshal-by-referenceobjectsandeventsinks.Mostlynot,though.ThisarticlelooksatthebasictechnologiesthatsupportXMLWebservicesandprovidesabriefdemonstrationofhowtoproduceandconsumeWebservices.

XMLWebServicesWillDo

XMLWebservicesin.NETarebuiltontopof.NETRemoting.Forallintentsandpurposes,aWebserviceismarshal-by-value.NETRemoting.Therumormillalsosuggeststhat.NETRemotingmaybecompletelyconcealedbyXMLWebservicesinthefuture,makingadvancedfeaturesofRemotinglikeeventsinksavailableusingWebservices.IhopeyouaremorecomfortablewithXMLWebservices.Now,whenyouhavetochoosebetweenRemotingandWebservices,youarepreparedtomakeadecision.Mostofthetimewhenyoucreatedistributedapplications,XMLWebserviceswilldo.

22:18

固定链接|评论(0)|引用通告(0)|记录它|.NETFRAMEWORK

固定链接

关闭

http://spaces.msn.com/members/glasscao/Blog/cns!1p-TWH5oRY7QQCLjMt-Lir6g!171.entry

XMLWebservices.NETRemotingandSystem.NETCommunicationGuidelines

1.AnXMLWebServicecallisessentiallyaSOAPmessagesentovertheHttpProtocol2..NETRemotingisacommunicationinfrastructurethatprovidesaccesstoremoteobjectsovertheTCPprotocol,Httpprotocolorsomeothercustomprotocol3.XMLWebServicesusesSOAP(SimpleObjectAccessProtocol)whichisanXMLmessagetocommunicateoverthewidelyusedHttpprotocol.4..NETRemotingprovidesobjectservicesovertheHttporTCPprotocol..NETRemotingcouldbeaSOAPmessageoveraHttpprotocol(similartoXMLWebservice)oraTCPprotocoloraBinaryFormattedmessageovertheTCPProtocolorHttpProtocol.5.WhenobjectsareremotedoveraTCPProtocolusingBinaryFormattingorEncodingyouhavethebestperformanceoverany.NETRemotingServiceorXMLWebservice.6.IfyouintendtosendSOAPmessagesovertheHttpprotocol,donotuse.NETRemoting,useXMLWebservices.ThemediumisthesameinbothinstancesandXMLWebservicesdelivermorespeedthan.NETRemotingserviceusingSOAPFormattingoveraHttpprotocol.7.UsingIISasaHostorserveroffersscalabilitytobothRemotedobjectsandXMLWebServices.XMLWebServicesuseIIS(InternetInformationServer)asaHostand.NETRemotingcanuseIIS,WindowsServices,WindowsForm,ConsoleApplicationasaHostorServer.8.YoucanbuildyourowninterprocesscommunicationsolutionusingclassesfromtheSystem.NETnamesapce.9.UsingIISasahostforXMLWebservicesor.NETRemotingserviceofferssecurityfeatureslikeauthenticationandalsostatemanagement.10.BinaryFormattingovertheTCPprotocolrequiresadditionalportsotherthatport80(whichIISuses)tobeopenedonyourwebserver.Theseadditionalportscouldposesecurityconsiderations.11.Using.NETRemotingofferssomeflexibilityfortheactivationofobjects(theycanbeactivatedontheserverorclient),objectlifetimemanagementusingleasesandobjectinstantiationmanagement(SingleCallorSingletonmodes.)12..NETRemotingoffersaccesstoaricherobjectorientedprogrammingmodelthan.XMLWebservices.13.XMLWebservicesoffersarichersetofoptionsforformattingSOAPmessagesthanSOAPFormattingina.NETRemotingContext.14.XMLWebservicesusesSOAPtocommunicatebetweentwocomputersandisbettersuitedforexchangingmessageswithapplicationsnotbuiltwith.NETwhile.NETRemotingisoptimizedforexchangingmessagesbetween.NETclients.

22:11

固定链接|评论(0)|引用通告(0)|记录它|.NETFRAMEWORK

固定链接

关闭

http://spaces.msn.com/members/glasscao/Blog/cns!1p-TWH5oRY7QQCLjMt-Lir6g!170.entry

设计.NET应用程序

升级到Microsoft.NETPaulD.SheriffPDSA,Inc.2002年4月出处：Microsoft摘要：本文概要介绍.NET应用程序中的各种典型物理结构之间的区别，这些结构已被证明是很有用的。针对每种结构介绍了其适用方案、实现方式和优缺点。本文同时介绍了两层、三层和N层应用程序。注意：

本文所介绍的应用程序设计问题在MSDN?的BuildingDistributedApplicationswith.NET（英文）部分中进行了更深入的讨论。

目标

了解Microsoft?.NET应用程序的典型结构。了解在每种结构内进行开发的优缺点。

前提条件

熟悉.NET开发（包括Web开发和桌面开发）。熟悉编程概念（包括类和属性）。熟悉各种结构（包括多层和多服务器结构）。目录两层应用程序结构

使用XMLWebService的三层应用程序

使用.NETRemoting的三层应用程序

逻辑N层应用程序

使用XMLWebService的N层应用程序

其他N层应用程序技术

迁移VisualBasic6.0的N层应用程序

小结

两层应用程序结构

典型的两层应用程序是使用ADO.NET直接与数据库服务器（如MicrosoftSQLServer?）进行通信的客户端应用程序（参见图1）。除ADO.NET外，在客户端应用程序和数据库之间没有任何其他层。有关ADO.NET的详细信息，请参阅.NET框架文档、本系列的其他文章或使用MSDN搜索引擎。图1：两层应用程序包括客户端应用程序和数据存储（如MicrosoftSQLServer）

何时使用两层结构

两层应用程序适用于没有或只有少量窗体的小型应用程序。对于使用本文中介绍的其他N层技术的应用程序，其原型也可算是两层应用程序。但是，两层应用程序不太适用于企业环境，因为开发和维护的时间及成本不好控制。

典型的实现方式

开发两层应用程序时可以采用多种技术。所有技术均使用ADO.NET、一个客户端界面（如桌面或基于Web的应用程序）和一个数据库（如SQLServer）。要使用两层应用程序结构，可以采用以下方式：使用数据绑定技术将ADO.NET数据集直接与控件连接。编写代码以访问ADO.NET对象，从而手动将数据加载到用户界面的控件中。使用上述两种技术的组合。使用上述任何技术直接在窗体上编写业务规则代码。

优点

两层应用程序具有以下优点：因为可以使用数据绑定将ADO.NET数据集直接与用于构建用户界面的很多控件连接，所以开发工作就变得简单而快捷。这有助于迅速建立并运行应用程序的基本功能。只需查看窗体便可以浏览应用程序的全部代码，而无须同时查看窗体和另一个组件。

缺点

两层应用程序开发方法具有以下缺点：所有业务规则均包含在前端代码中。因而，如果需要更改业务规则，则必须更新全部客户端。除非能够进行自动更新，否则这种维护工作将十分繁琐。当然，如果使用SQLServer，则可以将某些业务规则放到存储过程中，从而减少维护的时间和成本。尽管SQL可以在数据库结构和应用程序的其他部分之间提供某种程度的精简，但字段名称通常还是在源代码或控件属性中硬编码的。如果更改字段名称，则必须查找和替换应用程序中所有该字段的名称。如果使用了数据绑定，还必须检查所有窗体并更改属性。很多代码（如SQL语句和业务规则）常常在应用程序中重复出现，这是因为不同的窗体使用了某些相同的表。这使得此类应用程序的维护非常困难，因为如果需要更改表或字段的名称，则必须在多个位置进行更改，同时还需要在多个位置进行额外的回归测试。如果数据源发生变化，则对用于将数据加载到数据集的代码的更改将更加困难。例如，如果原来使用文本文件存储数据，然后又希望转换到SQLServer，其访问方式是截然不同的。此外，要将数据加载到应用程序的数据集，还有很多地方都需要更改代码。

使用XMLWebService的三层应用程序

另一种设计方式是使用XMLWebservice，将数据库的访问单独分给另一个组件，该组件将把数据返回到前端应用程序。图2显示了这种设计方式。有关使用XMLWebservices开发三层应用程序的详细信息，请使用MSDN搜索引擎。图2：使用XMLWebservice将数据库层与前端代码分离

何时使用此技术

使用XMLWebservice的三层应用程序适用于基于Web的应用程序或MicrosoftWindows?应用程序。如果需要桌面应用程序的丰富功能，而用户连接自多个不同的位置，并通过HTTP界面访问数据，则很适合使用此技术。

典型的实现方式

要创建三层/XMLWebservice应用程序，通常采用以下开发技术：所有SQL驻留在XMLWebservice中。在服务器上构建数据集，并将其作为XML流返回到客户端，它们在这里又可以重新被构建为数据集。可以将从XMLWebservice返回的数据集直接绑定到窗体的控件中。可以使用从XMLWebservice返回的数据集手动将数据加载到窗体的各种控件中。直接在窗体上编写所有业务规则的代码。

优点

使用XMLWebservice的三层应用程序具有以下优点：因为可以使用数据绑定将ADO.NET数据集直接与用于构建用户界面的很多控件连接，所以开发工作就变得简单而快捷。这有助于迅速建立并运行应用程序的基本功能。用户可以从能连接到Internet（或Intranet）的任何地方运行应用程序。数据库访问被单独分给自己的组件，这样就无需在前端代码中嵌入SQL。连接信息只保留在XMLWebservice上，同样减少了客户端计算机的维护工作。可以在某个中心位置更新数据库访问层。如果对此层进行简单的代码更改，则无需重新向客户端分发组件。

缺点

此设计的缺点与典型的两层应用程序的缺点基本相同，因为它并没有分离业务规则，而只是分离了数据层。此外，表中的列名称也没有被提取到类中（将在下一节中介绍）。所有业务规则均包含在前端代码中。因而，如果需要更改业务规则，则必须更新全部客户端。除非能够进行自动更新，否则这种维护工作将十分繁琐。当然，如果使用SQLServer，则可以将某些业务规则放到存储过程中，从而减少维护的时间和成本。所有字段名称均在源代码或控件属性中硬编码。如果更改字段名称，则必须查找和替换应用程序中所有该字段的名称。如果使用了数据绑定，还必须检查所有窗体并更改属性。通过HTTP界面进行访问比直接连接数据库要慢。如果用户无法访问Internet（或Intranet），则无法使用该应用程序。

使用.NETRemoting的三层应用程序

这种类型的应用程序结构与使用XMLWebservice的三层应用程序几乎完全相同。唯一的区别是使用.NETRemoting代替XMLWebservice来包装数据访问层。图3显示了这种设计方式。有关.NETRemoting的详细信息，请参阅本系列的其他文章或使用MSDN搜索引擎。

图3：在LAN环境中，可以使用.NETRemoting来包装数据访问层

何时使用三层.NETRemoting技术

使用.NETRemoting的三层应用程序适用于必须在LAN中的计算机之间分布的应用程序。这可能是出于业务原因，或者考虑到所涉及的工作成本，采用网络呼叫比较合理。

典型的实现方式

要创建这种应用程序，通常采用以下开发技术：所有SQL驻留在通过Remoting服务调用的组件中。在服务器上构建数据集，并将其作为XML流返回到客户端，它们在这里又可以重新被构建为数据集。将从Remoting组件返回的数据集直接绑定到窗体的控件中。使用从Remoting组件返回的数据集手动将数据加载到窗体的不同控件中。直接在窗体上编写所有业务规则的代码。

优点

使用.NETRemoting的三层应用程序与使用XMLWebservice的三层应用程序具有相同的基本优点。因为可以使用数据绑定将ADO.NET数据集直接与用于创建用户界面的很多控件连接，所以编写三层应用程序就变得简单而快捷。这有助于迅速建立并运行应用程序的基本功能。用户可以从能连接到LAN或WAN的任何地方运行应用程序。数据库访问被单独分给另一个组件，这样就无需在前端代码中嵌入SQL。可以在某个中心位置更新数据库访问层。如果在此组件中进行简单的代码更改，则无需重新向客户端分发组件。注意：

所有N层结构都具有此优点。

缺点

这种三层设计的缺点与使用XMLWebservice的三层设计的缺点相同。所有业务规则均包含在前端代码中。因而，如果需要更改业务规则，则必须更新全部客户端。除非能够进行自动更新，否则这种维护工作将十分繁琐。当然，如果使用SQLServer，则可以将某些业务规则放到存储过程中，从而减少维护的时间和成本。所有字段名称均在源代码或控件属性中硬编码。如果更改字段名称，则必须查找和替换应用程序中所有该字段的名称。如果使用了数据绑定，还必须检查所有窗体并更改属性。通过网络从一个组件向另一个组件传输数据比直接连接数据库要慢。在Intranet方案中，.NETRemoting的性能比XMLWebservice要好。而在Internet方案中，一般不使用.NETRemoting。建立这种应用程序比建立两层应用程序或使用XMLWebservice的应用程序要复杂一些。

逻辑N层应用程序

使用.NET创建应用程序的最好方法是将所有逻辑进程分为不同的类。在典型的业务应用程序中，这通常包含业务规则组件、数据层组件和使用这些组件的前端代码。图4显示了这一方法。有关设计N层应用程序的详细信息，请参阅本系列的其他文章或使用MSDN搜索引擎。<图4：将业务进程分解为不同的类，从而使应用程序更易于创建和维护

何时使用N层结构

逻辑N层开发策略适用于所有类型的应用程序。无论是小型、中型、大型应用程序，还是桌面或Web应用程序，效果都很好。

典型的实现方式

要创建这种应用程序，通常采用以下开发技术：使用Windows窗体或Web窗体创建前端用户界面。使用单独的类库项目创建业务规则组件。使用单独的类库项目创建数据层组件。此数据层使用类来包装对各个表的访问。应当使用类型化数据集；它们提供了灵活的数据集类，并且为表中的每个列提供了严格的类型检查功能。

优点

逻辑N层应用程序具有以下优点：将业务规则集中到易于创建、使用和重用的组件中，从而方便了开发和维护。提供了高级语言以开发业务规则，代替使用存储过程和有限的SQL语言来检查业务规则。将数据访问集中到组件中，从而减少了应用程序中的重复代码，每个需要访问特定表的窗体都使用相同的组件。如果使用类型化数据集，则可以使用智能感知功能来查询列名称，而不必记住它们。集中式数据访问例程有助于维护工作，因为对任何数据访问例程的更改都只需进行一次即可。可以随时将组件分离到不同的物理计算机上。这种灵活性使代码具有更好的可缩放性和集中性。

缺点

逻辑N层应用程序只有两个较大的缺点：开发时间稍长，因为必须构建单独的组件。需要跟踪的组件会多一些。这使其略显复杂，对于编程新手来说可能不太好理解。

使用XMLWebService的N层应用程序

图5显示了如何进行逻辑N层应用程序设计并将其分布于多台计算机的示例。在此图中，可以看到使用了XMLWebservice来访问数据层。类型化数据集通过HTTP层返回到业务规则层。然后，客户端应用程序可以将该数据集用于用户界面的数据显示。图5：将业务进程分离到单独的计算机中以利于部署和维护

何时使用此技术

如果需要桌面应用程序的丰富功能，而用户可能连接自很多远程位置，并且需要通过HTTP界面来获取数据，那么就可以采用这种N层XMLWebservice应用程序设计。将业务规则保留在客户端上有利于网络畅通，但如果这些规则更改频繁，则会增加一些维护更新工作。由于.NET可以复制新的DLL而无需注册，所以这些问题已经不象在以前的技术中那样严重。这种方案也适用于基于Web的应用程序，其中由一台Web服务器提供数据，而由另一台Web服务器上的Web应用程序显示此数据。

典型的实现方式

要创建这种应用程序，通常采用以下开发技术：这些技术与逻辑N层应用程序中的技术相同。使用Windows窗体或Web窗体创建前端用户界面。使用单独的类库项目创建业务规则组件。使用单独的类库项目创建数据层组件。此数据层使用类来包装对各个表的访问。应当使用类型化数据集；它们提供了灵活的数据集类，并且为表中的每个列提供了严格的类型检查功能。

优点

使用XMLWebservice的N层应用程序具有多个优点，其中很多与逻辑N层应用程序相同。将业务规则集中到易于创建、使用和重用的组件中，从而方便了开发和维护。提供了高级语言以开发业务规则，代替使用存储过程和有限的SQL语言来检查业务规则。将数据访问集中到组件中，从而减少了应用程序中的重复代码，每个需要访问特定表的窗体都使用相同的组件。如果使用类型化数据集，则可以使用智能感知功能来查询列名称，而不必记住它们。集中式数据访问例程有助于维护工作，因为对任何数据访问例程的更改都只需进行一次即可。可以随时将组件分离到不同的物理计算机上。这种灵活性使代码具有更好的可缩放性和集中性。其他优点：集中式数据访问层。其他优点：应用程序的可扩展性-可以添加Web领域以处理用户对数据库的请求的大量负载。其他优点：用户可以通过Internet进行连接，但仍从桌面或基于Web的应用程序访问数据。

缺点

使用XMLWebservice的N层应用程序开发方法也有一些缺点。其中大部分与使用逻辑N层应用程序开发方案的缺点相同。开发时间稍长，因为必须构建单独的组件。需要跟踪的组件会多一些。这使其略显复杂，对于编程新手来说可能不太好理解。如果XMLWebservice不能正常工作，该应用程序将无法使用。

其他N层应用程序技术

当然，可以采用很多不同的技术来创建N层应用程序。例如，可以使用.NETRemoting在客户端层和业务规则层之间进行通信，如图6所示。图6：可以组合使用.NETRemoting和XMLWebservices，为应用程序提供最佳的可缩放性和可维护性使用N层技术开发应用程序后，还可以采用多种方法对其进行配置。可以组合使用.NET中的任何可用方法来分离应用程序的各层。

迁移VisualBasic6.0的N层应用程序

程序员在以前版本的MicrosoftVisualBasic?中使用N层技术已经有很多年了。如果有现成的COM组件，则可以很容易地为这些组件上加上.NET包装。之后，便可以获得如图7所示的结构。有关在.NET中使用COM组件的详细信息，请参阅本系列的其他文章或使用MSDNWeb站点中的搜索引擎。

图7：使用.NET可以方便地建立原有COM组件的接口

何时使用VisualBasic迁移技术

如果具有大量的COM组件代码，并且这些组件已经包含了您的业务规则和数据访问例程，则适合使用这种技术。因为可以利用很多现有代码，从而降低进入.NET框架的成本。

典型的实现方式

要创建这种应用程序，通常采用以下开发技术：使用Windows窗体或Web窗体创建前端用户界面。设置对原有COMDLL的引用。Microsoft.NET自动为此DLL创建一个.NET包装，因此可以象对任何.NET组件那样访问其属性和方法。如果从该DLL中返回任何ADO记录集，则可以将它们转换为数据集，这是绑定到.NET控件的最简单的方法。

优点

在COM接口外加上.NET包装，可以在使用现有代码的同时充分利用.NET的新功能，从而缩短开发周期。

缺点

在.NET中使用COM包装具有以下缺点：其性能不如完全在.NET中编写的代码。可能需要额外的代码以将ADO记录集转换为ADO.NET数据集。

小结

在开发.NET应用程序时，可以采用的结构形式几乎是无限的。易于创建和维护的结构才是最好的。当然，还要考虑其他设计目标，包括可缩放性、可靠性和可管理性等。在MSDN中，您可以找到许多相关主题的白皮书。

2005-7-19

ADO.NET创建关联的范例

SqlConnectioncustConn=newSqlConnection("DataSource=localhost;IntegratedSecurity=SSPI;InitialCatalog=northwind;");SqlDataAdaptercustDA=newSqlDataAdapter("SELECT*FROMCustomers",custConn);OleDbConnectionorderConn=newOleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;"+"DataSource=c:\\ProgramFiles\\MicrosoftOffice\\Office\\Samples\\northwind.mdb;");OleDbDataAdapterorderDA=newOleDbDataAdapter("SELECT*FROMOrders",orderConn);custConn.Open();orderConn.Open();DataSetcustDS=newDataSet();custDA.Fill(custDS,"Customers");orderDA.Fill(custDS,"Orders");custConn.Close();orderConn.Close();DataRelationcustOrderRel=custDS.Relations.Add("CustOrders",custDS.Tables["Customers"].Columns["CustomerID"],custDS.Tables["Orders"].Columns["CustomerID"]);foreach(DataRowpRowincustDS.Tables["Customers"].Rows){Console.WriteLine(pRow["CustomerID"]);foreach(DataRowcRowinpRow.GetChildRows(custOrderRel))Console.WriteLine("\t"+cRow["OrderID"]);}

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航