WCF egyszerűsítési funkciók

Ez a témakör azokat az új funkciókat ismerteti, amelyek egyszerűbbé teszik a WCF-alkalmazások írását.

gRPC a WCF alternatívaként

A gRPC egy modern RPC-keretrendszer, amely a WCF népszerű alternatíva. A gRPC a HTTP/2-n alapul, amely számos előnyt biztosít a WCF-sel szemben, beleértve a következőket:

Teljesítmény: a gRPC sokkal hatékonyabb, mint a WCF, különösen a hosszú ideig futó kapcsolatok esetében.
Méretezhetőség: a gRPC nagy számú ügyfélre és kiszolgálóra skálázható.
Biztonság: a gRPC számos biztonsági mechanizmust támogat, beleértve a TLS-t és a hitelesítést.
Platformfüggetlen: a gRPC platformsemleges, és számos programozási nyelvvel használható.

A WCF-alkalmazások gRPC-be való fejlesztésével vagy migrálásával kapcsolatos további információkért lásd:

Egyszerűsített generált konfigurációs fájlok

Amikor hozzáad egy szolgáltatáshivatkozást a Visual Studióban, vagy használja a SvcUtil.exe eszközt, létrejön egy ügyfélkonfigurációs fájl. A WCF korábbi verzióiban ezek a konfigurációs fájlok minden kötéstulajdonság értékét tartalmazzák, még akkor is, ha az értéke az alapértelmezett érték. A WCF 4.5-ben a létrehozott konfigurációs fájlok csak azokat a kötési tulajdonságokat tartalmazzák, amelyek nem alapértelmezett értékre vannak beállítva.

Az alábbiakban egy példa látható a WCF 3.0 által létrehozott konfigurációs fájlra.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false"
                    hostNameComparisonMode="StrongWildcard" maxBufferSize="65536"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192"
                        maxArrayLength="16384" maxBytesPerRead="4096"
                        maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Az alábbiakban egy példa látható a WCF 4.5 által létrehozott konfigurációs fájlra.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" />
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Contract-First fejlesztés

A WCF mostantól támogatja a szerződés-első fejlesztési folyamatot. A svcutil.exe eszköz /serviceContract kapcsolóval rendelkezik, amellyel szolgáltatási és adatszerződéseket hozhat létre egy WSDL-dokumentumból.

Szolgáltatáshivatkozás hozzáadása hordozható részhalmazprojektből

A hordozható részhalmazprojektek lehetővé teszik, hogy a .NET-szerelvényprogramozók egyetlen forrásfát tartsanak fenn, és rendszert építsenek, miközben több .NET-implementációt is támogatnak (asztali, Silverlight, Windows Phone és Xbox). A hordozható részhalmazprojektek csak olyan .NET-hordozható kódtárakra hivatkoznak, amelyek bármely .NET-implementációban használhatók. A fejlesztői élmény ugyanaz, mint egy szolgáltatáshivatkozás hozzáadása bármely más WCF-ügyfélalkalmazásban. A további információkért lásd: Szolgáltatáshivatkozás hozzáadása hordozható részhalmazprojektekben.

ASP.NET kompatibilitási mód alapértelmezett módosítása

A WCF ASP.NET kompatibilitási módot biztosít a fejlesztőknek, hogy teljes hozzáférést biztosítsanak a ASP.NET HTTP-folyamat funkcióihoz a WCF-szolgáltatások írásakor. A mód használatához az aspNetCompatibilityEnabled attribútumot igaz értékre kell állítania a <web.configserviceHostingEnvironment> szakaszában. Ezenkívül az appDomain bármely szolgáltatásának rendelkeznie kell a RequirementsMode tulajdonság beállításával AspNetCompatibilityRequirementsAttribute, amelyet Allowed vagy Required értékre kell állítani. Alapértelmezés szerint a AspNetCompatibilityRequirementsAttribute mostantól a Allowed értékre van beállítva, és az alapértelmezett WCF szolgáltatásalkalmazás-sablon a aspNetCompatibilityEnabled attribútumot a true értékre állítja be. További információ: A Windows Communication Foundation 4.5 újdonságai , a WCF-szolgáltatások és ASP.NET.

Streamelési fejlesztések

Az aszinkron streamelés új támogatása lett hozzáadva a WCF-hez. Az aszinkron streamelés engedélyezéséhez adja hozzá a DispatcherSynchronizationBehavior végponti viselkedést a szolgáltatásgazdához, és állítsa be a AsynchronousSendEnabled tulajdonságot true értékre. Ez akkor lehet hasznos, ha egy szolgáltatás streamelt üzeneteket küld több olyan ügyfélnek, amelyek lassan olvasnak. A WCF már nem blokkolja az ügyfélenként egy szálat, és felszabadítja a szálat egy másik ügyfél kiszolgálásához.
Az üzenetek pufferelésével kapcsolatos korlátozások el lettek távolítva, amikor egy szolgáltatás IIS-t üzemeltet. A WCF korábbi verzióiban, amikor egy streamelt üzenetátvitelt használó IIS-szolgáltatáshoz kapott üzenetet, ASP.NET pufferelné a teljes üzenetet, mielőtt elküldené azt a WCF-nek. Ez nagy memóriahasználatot okozna. Ez a pufferelés el lett távolítva a .NET-keretrendszer 4.5-ös verziójában, és az IIS által üzemeltetett WCF-szolgáltatások megkezdhetik a bejövő stream feldolgozását a teljes üzenet fogadása előtt, ezáltal lehetővé téve a valódi streamelést. Ez lehetővé teszi, hogy a WCF azonnal válaszoljon az üzenetekre, és jobb teljesítményt biztosít. Emellett már nem kell megadnia a bejövő kérelmek méretkorlátjának ASP.NET értékét maxRequestLength. Ha ez a tulajdonság be van állítva, a rendszer figyelmen kívül hagyja. További információ a maxRequestLength<. Továbbra is konfigurálnia kell a maxAllowedContentLength elemet. További információ: IIS-kérelmek korlátai.

Új átviteli alapértelmezett értékek

Az alábbi táblázat a módosított beállításokat és a további információk megkeresésének helyét ismerteti.

Ingatlan	Bekapcsolva	Új alapértelmezett	További információ
csatornaInicializálásiIdőtúllépés	NetTcpBinding	30 másodperc	Ez a tulajdonság határozza meg, hogy egy TCP-kapcsolat mennyi ideig tarthat a .NET Framing protokoll használatával történő hitelesítéshez. Az ügyfélnek el kell küldenie néhány kezdeti adatot, mielőtt a kiszolgáló elegendő információval rendelkezik a hitelesítés végrehajtásához. Ez az időtúllépés szándékosan kisebb, mint a ReceiveTimeout (10 perc), így a rosszindulatú, hitelesítés nélküli ügyfelek nem tartják sokáig a kiszolgálóhoz kötött kapcsolatokat. Az alapértelmezett érték 30 másodperc. További információ: ChannelInitializationTimeout
visszahallgatási lista	NetTcpBinding	16 * processzorok száma	Ez a foglalatszintű tulajdonság a várólistára helyezendő "függőben lévő elfogadás" kérések számát írja le. Ha a figyelés várólistája megtelik, a rendszer elutasítja az új socket kéréseket. További információ: ListenBacklog
maxPendingAccepts	ConnectionOrientedTransportBindingElement SMSvcHost.exe	2 * szállítási processzorok száma 4 * a processzorok száma SMSvcHost.exe	Ez a tulajdonság korlátozza a kiszolgáló által a figyelőre várakozó csatornák számát. Ha a MaxPendingAccepts értéke túl alacsony, lesz egy rövid időszak, amikor az összes várakozó csatorna megkezdte a kapcsolatok kiszolgálását, de új csatornák még nem kezdték el a figyelést. A kapcsolat ebben az időszakban meg tud érkezni, és sikertelen lesz, mert semmi sem vár rá a kiszolgálón. Ezt a tulajdonságot úgy lehet konfigurálni, hogy a MaxPendingConnections tulajdonságot nagyobb számra állítja. További információkért lásd MaxPendingAccepts és konfigurálja a Net.TCP portmegosztási szolgáltatást
maxPendingConnections	ConnectionOrientedTransportBindingElement	12 * processzorok száma	Ez a tulajdonság azt szabályozza, hogy a szállítás hány kapcsolatot fogadott el, de ezeket még nem vette fel a ServiceModel Dispatcher. Az érték beállításához használja a `MaxConnections` a kötésen vagy a `maxOutboundConnectionsPerEndpoint` a kötési elemen. További információ: MaxPendingConnections
receiveTimeout	SMSvcHost.exe	30 másodperc	Ez a tulajdonság azt az időtúllépést adja meg, amely a TCP-keretezési adatok beolvasására és a mögöttes kapcsolatokból való kapcsolatküldés végrehajtására használható. Ez azt a határidőt határozza meg, ameddig a SMSvcHost.exe szolgáltatás foglalt marad a bejövő kapcsolaton érkező preambulumadatok beolvasása céljából. További információ: A Net.TCP portmegosztási szolgáltatás konfigurálása.

Megjegyzés:

Ezeket az új alapértelmezett értékeket csak akkor használja a rendszer, ha a WCF szolgáltatást a .NET-keretrendszer 4.5-ös verzióját használó gépen helyezi üzembe. Ha ugyanazt a szolgáltatást egy .NET-keretrendszer 4.0-s verzióját használó gépen helyezi üzembe, akkor a .NET-keretrendszer 4.0-s alapértelmezései lesznek használatban. Ilyen esetekben javasoljuk, hogy ezeket a beállításokat explicit módon konfigurálja.

XmlDictionaryReaderQuotas

XmlDictionaryReaderQuotas Olyan konfigurálható kvótaértékeket tartalmaz az XML-szótárolvasók számára, amelyek korlátozzák a kódoló által az üzenet létrehozásakor felhasznált memória mennyiségét. Bár ezek a kvóták konfigurálhatók, az alapértelmezett értékek módosultak, így csökkentve annak lehetőségét, hogy a fejlesztőnek explicit módon kell beállítania őket. MaxReceivedMessageSize a kvóta nem módosult, így továbbra is korlátozhatja a memóriahasználatot, megakadályozva, hogy Önnek foglalkoznia kelljen a XmlDictionaryReaderQuotas összetettségével. Az alábbi táblázat a kvótákat, az új alapértelmezett értékeket és az egyes kvóták felhasználásának rövid ismertetését mutatja be.

Kvóta neve	Alapértelmezett érték	Leírás
MaxArrayLength	Int32.MaxValue	Lekéri és beállítja a maximálisan megengedett tömbhosszt. Ez a kvóta korlátozza az XML-olvasó által visszaadott primitív tömbök maximális méretét, beleértve a bájttömböket is. Ez a kvóta nem korlátozza a memóriahasználatot az XML-olvasóban, hanem bármilyen összetevőben, amely az olvasót használja. Például, amikor a DataContractSerializer egy MaxArrayLength-tel védett olvasót használ, akkor nem deszerializálja a kvótánál nagyobb méretű bájttömböket.
MaxBytesPerRead	Int32.MaxValue	Meghatározza és beállítja a minden egyes olvasáshoz visszaadott megengedett maximális bájtok számát. Ez a kvóta korlátozza az egyetlen olvasási műveletben beolvasott bájtok számát az elem kezdőcímkéjének és attribútumainak olvasásakor. (Nem streamelt esetekben maga az elem neve nem számít bele a kvótába). Ha túl sok XML-attribútumot használ, az aránytalan feldolgozási időt is igénybe vehet, mivel az attribútumnevek egyediségét ellenőrizni kell. MaxBytesPerRead elhárítja ezt a fenyegetést.
MaxDepth	128 csomópont mély	Ez a kvóta korlátozza az XML-elemek maximális beágyazási mélységét. MaxDepth a következővel MaxBytesPerReadkommunikál: az olvasó mindig a memóriában tartja az adatokat az aktuális elem és az összes elődje számára, így az olvasó maximális memóriahasználata arányos a két beállítás szorzatával. Mélyen beágyazott objektumgrafikon deszerializálásakor a deszerializálónak az egész veremhez hozzá kell férnie, és vissza nem állítható StackOverflowException kivételt kell dobnia. Közvetlen korreláció áll fenn az XML-beágyazás és az objektumok beágyazása között mind a DataContractSerializer, mind a XmlSerializer esetében. MaxDepth a fenyegetés mérséklésére szolgál.
MaxNameTableCharCount	Int32.MaxValue	Ez a kvóta korlátozza a névtáblában megengedett karakterek maximális számát. A névtábla bizonyos sztringeket (például névtereket és előtagokat) tartalmaz, amelyek egy XML-dokumentum feldolgozásakor lépnek fel. Mivel ezek a sztringek pufferelve vannak a memóriában, ez a kvóta megakadályozza a túlzott pufferelést, amikor a streamelés várható.
MaxStringContentLength	Int32.MaxValue	Ez a kvóta korlátozza az XML-olvasó által visszaadott maximális sztringméretet. Ez a kvóta nem korlátozza a memóriahasználatot az XML-olvasóban, hanem az olvasót használó összetevőben. Ha például egy DataContractSerializer olvasót, amelyet MaxStringContentLength-vel biztosítottak, használnak, nem fogja deszerializálni az ennél a kvótánál nagyobb karaktersorozatokat.

Fontos

Az adatok biztonságával kapcsolatos további információkért tekintse meg az "XML biztonságos használata" című témakört az Adatok biztonsági szempontjai között.

Megjegyzés:

WCF-konfiguráció ellenőrzése

A Visual Studióban a felépítési folyamat részeként most már érvényesítik a WCF-konfigurációs fájlokat. Ha az ellenőrzés sikertelen, megjelenik az érvényesítési hibák vagy figyelmeztetések listája a Visual Studióban.

XML-szerkesztő eszköztippek

Annak érdekében, hogy az új és meglévő WCF-szolgáltatásfejlesztők konfigurálhassák szolgáltatásaikat, a Visual Studio XML-szerkesztő mostantól elemleírásokat biztosít a szolgáltatáskonfigurációs fájl részét képező összes konfigurációelemhez és tulajdonságaihoz.

AlapszintűhttpBinding-fejlesztések

Lehetővé teszi, hogy egyetlen WCF-végpont válaszoljon a különböző hitelesítési módokra.
Lehetővé teszi, hogy a WCF-szolgáltatás biztonsági beállításait az IIS vezérelje

Last updated on 2025-06-17