Megosztás a következőn keresztül:

A WCF webes HTTP-szolgáltatások gyorsítótárazási támogatása

  • Cikk

.NET-keretrendszer 4.6.1 lehetővé teszi, hogy a WCF webes HTTP-szolgáltatásaiban már elérhető deklaratív gyorsítótárazási mechanizmust használja ASP.NET. Így gyorsítótárazhatja a WCF webes HTTP-szolgáltatás műveleteiből érkező válaszokat. Amikor egy felhasználó gyorsítótárazáshoz konfigurált HTTP GET-t küld a szolgáltatásnak, ASP.NET visszaküldi a gyorsítótárazott választ, és a szolgáltatás metódusa nem lesz meghívva. Amikor a gyorsítótár lejár, a következő alkalommal, amikor egy felhasználó HTTP GET-t küld, meghívja a szolgáltatás metódusát, és a rendszer ismét gyorsítótárazza a választ. A ASP.NET gyorsítótárazással kapcsolatos további információkért lásd ASP.NET gyorsítótárazási áttekintést.

Alapszintű webes HTTP-szolgáltatás gyorsítótárazása

A WEB HTTP-szolgáltatás gyorsítótárazásának engedélyezéséhez először engedélyeznie kell a ASP.NET kompatibilitást a AspNetCompatibilityRequirementsAttribute szolgáltatásra vonatkozó beállítás RequirementsModeAllowed alkalmazásával.Required

.NET-keretrendszer 4 egy új attribútumot vezet AspNetCacheProfileAttribute be, amely lehetővé teszi a gyorsítótárprofil nevének megadását. Ez az attribútum egy szolgáltatásműveletre lesz alkalmazva. Az alábbi példa egy szolgáltatásra alkalmazza a AspNetCompatibilityRequirementsAttribute ASP.NET kompatibilitásának engedélyezéséhez és a GetCustomer gyorsítótárazási művelet konfigurálásához. Az AspNetCacheProfileAttribute attribútum egy gyorsítótárprofilt ad meg, amely tartalmazza a használni kívánt gyorsítótár-beállításokat.

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
public class Service
{
    [WebGet(UriTemplate = "{id}")]
    [AspNetCacheProfile("CacheFor60Seconds")]
    public Customer GetCustomer(string id)
    {
        // ...
    }
}

Kapcsolja be ASP.NET kompatibilitási módot is a Web.config fájlban az alábbi példában látható módon.

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>

Figyelmeztetés

Ha ASP.NET kompatibilitási mód nincs bekapcsolva, és a AspNetCacheProfileAttribute rendszer kivételt alkalmaz.

A gyorsítótárprofil által megadott név azonosítja a AspNetCacheProfileAttribute Web.config konfigurációs fájlhoz hozzáadott gyorsítótárprofilt. A gyorsítótárprofil egy <outputCacheSetting> elemben van definiálva, ahogyan az a következő konfigurációs példában is látható.

<!-- ...  -->
<system.web>  
   <caching>  
      <outputCacheSettings>  
         <outputCacheProfiles>  
            <add name="CacheFor60Seconds" duration="60" varyByParam="none" sqlDependency="MyTestDatabase:MyTable"/>  
         </outputCacheProfiles>  
      </outputCacheSettings>  
   </caching>  
   <!-- ... -->  
</system.web>

Ez ugyanaz a konfigurációs elem, amely ASP.NET alkalmazások számára érhető el. További információ ASP.NET gyorsítótárprofilokról: OutputCacheProfile. A webes HTTP-szolgáltatások esetében a gyorsítótárprofil legfontosabb attribútumai a következők: cacheDuration és varyByParam. Mindkét attribútumra szükség van. cacheDuration beállítja, hogy a válasz mennyi ideig legyen gyorsítótárazva másodpercben. varyByParam lehetővé teszi a válaszok gyorsítótárazásához használt lekérdezési sztringparaméter megadását. A különböző lekérdezési sztringparaméter-értékekkel végrehajtott összes kérés külön gyorsítótárazva lesz. Ha például egy kezdeti kérést küld http://MyServer/MyHttpService/MyOperation?param=10, az azonos URI-val küldött összes további kérés a gyorsítótárazott választ adja vissza (amennyiben a gyorsítótár időtartama nem telt el). Az azonos, de a paraméter lekérdezési sztring paraméteréhez eltérő értékkel rendelkező hasonló kérésekre adott válaszok külön gyorsítótárazva lesznek. Ha nem szeretné ezt a különálló gyorsítótárazási viselkedést, állítsa be a "none" értéket varyByParam .

SQL Cache-függőség

A webes HTTP-szolgáltatás válaszai SQL Cache-függőséggel is gyorsítótárazhatók. Ha a WCF webes HTTP-szolgáltatása egy SQL-adatbázisban tárolt adatoktól függ, érdemes lehet gyorsítótárazni a szolgáltatás válaszát, és érvényteleníteni a gyorsítótárazott választ, amikor az SQL-adatbázistáblában lévő adatok megváltoznak. Ez a viselkedés teljesen a Web.config fájlban van konfigurálva. Először definiáljon egy kapcsolati sztring az <connectionStrings> elemben.

<connectionStrings>
  <add name="connectString"
       connectionString="Data Source=MyService;Initial Catalog=MyTestDatabase;Integrated Security=True"
       providerName="System.Data.SqlClient" />
</connectionStrings>

Ezután engedélyeznie kell az SQL Cache-függőséget az elem egyik <caching> elemében az <system.web> alábbi konfigurációs példában látható módon.

<system.web>
  <caching>
    <sqlCacheDependency enabled="true" pollTime="1000">
      <databases>
        <add name="MyTestDatabase" connectionStringName="connectString" />
      </databases>
    </sqlCacheDependency>
    <!-- ... -->
  </caching>
  <!-- ... -->
</system.web>

Itt engedélyezve van az SQL Cache-függőség, és a lekérdezési idő 1000 ezredmásodperc. Minden alkalommal, amikor a lekérdezési idő eltelt, a rendszer ellenőrzi az adatbázistáblát a frissítések keresésekor. Ha a rendszer módosításokat észlel, a gyorsítótár tartalma el lesz távolítva, és a szolgáltatásművelet következő meghívásakor a rendszer új választ ad a gyorsítótárba. Az elemen <sqlCacheDependency> belül adja hozzá az adatbázisokat, és hivatkozzon az elemen belüli <databases> kapcsolati sztring az alábbi példában látható módon.

<system.web>
  <caching>
    <sqlCacheDependency enabled="true" pollTime="1000">
      <databases>
        <add name="MyTestDatabase" connectionStringName="connectString" />
      </databases>  
    </sqlCacheDependency>  
    <!-- ... -->  
  </caching>  
  <!-- ... -->  
</system.web>

Ezután konfigurálnia kell a kimeneti gyorsítótár beállításait az elemen belül az <caching> alábbi példában látható módon.

<system.web>
  <caching>  
    <!-- ...  -->
    <outputCacheSettings>
      <outputCacheProfiles>
        <add name="CacheFor60Seconds" duration="60" varyByParam="none" sqlDependency="MyTestDatabase:MyTable" />
      </outputCacheProfiles>
    </outputCacheSettings>
  </caching>
  <!-- ... -->
</system.web>

Itt a gyorsítótár időtartama 60 másodpercre van beállítva, varyByParam nincs, és sqlDependency pontosvesszővel tagolt adatbázis-név/táblázatpárok kettősponttal elválasztott listájára van beállítva. Az adatok MyTable módosításakor a szolgáltatásművelet gyorsítótárazott válasza törlődik, és a művelet meghívásakor új válasz jön létre (a szolgáltatásművelet meghívásával), gyorsítótárazva, és visszakerül az ügyfélhez.

Fontos

Ahhoz, hogy ASP.NET hozzáférhessen egy SQL-adatbázishoz, az ASP.NET SQL Server regisztrációs eszközt kell használnia. Emellett engedélyeznie kell a megfelelő felhasználói fiók hozzáférését az adatbázishoz és a táblához. További információ: SQL Server elérése webalkalmazásból.

Feltételes HTTP GET-alapú gyorsítótárazás

Webes HTTP-forgatókönyvekben a szolgáltatások gyakran használnak feltételes HTTP GET-t az intelligens HTTP-gyorsítótárazás megvalósításához a HTTP-specifikációban leírtak szerint. Ehhez a szolgáltatásnak be kell állítania az ETag fejléc értékét a HTTP-válaszban. A HTTP-kérelemben az If-None-Match fejlécet is ellenőriznie kell, hogy a megadott ETag valamelyike megfelel-e az aktuális ETagnek.

A GET és a HEAD kérelmek esetében egy ETag-értéket vesz fel, CheckConditionalRetrieve és ellenőrzi a kérés If-None-Match fejlécén. Ha az élőfej jelen van, és egyezés van, WebFaultException a rendszer egy 304-ben (nem módosított) HTTP-állapotkóddal rendelkező eTag-fejlécet ad hozzá a válaszhoz a megfelelő ETaggel.

A metódus egyik túlterhelése CheckConditionalRetrieve egy utolsó módosítási dátumot vesz igénybe, és ellenőrzi a kérés If-Modified-Since fejlécén. Ha a fejléc jelen van, és az erőforrás azóta nem lett módosítva, a WebFaultException rendszer egy 304-as (nem módosított) HTTP-állapotkóddal rendelkezik.

A PUT, POST és DELETE kérelmek CheckConditionalUpdate esetében az erőforrás aktuális ETag-értékét veszi fel. Ha az aktuális ETag értéke null, a metódus ellenőrzi, hogy az If-None- Egyezés fejléc "*" értékű-e. Ha az aktuális ETag-érték nem alapértelmezett érték, akkor a metódus ellenőrzi az aktuális ETag-értéket a kérés If- Egyezés fejlécén. A metódus mindkét esetben a 412-s HTTP-állapotkóddal ( WebFaultException az előkondicionálás sikertelen), ha a várt fejléc nem szerepel a kérelemben, vagy az értéke nem felel meg a feltételes ellenőrzésnek, és beállítja a válasz ETag-fejlécét az aktuális ETag-értékre.

Mind a CheckConditional metódus, mind a SetETag metódus biztosítja, hogy a válaszfejlécen beállított ETag érték érvényes ETag legyen a HTTP-specifikációnak megfelelően. Ez magában foglalja az ETag értékét dupla idézőjelekben, ha még nincsenek jelen, és megfelelő módon kerüli el a belső idézőjelek karaktereit. Gyenge ETag-összehasonlítás nem támogatott.

Az alábbi példa bemutatja, hogyan használhatja ezeket a metódusokat.

[WebGet(UriTemplate = "{id}"), Description("Returns the specified customer from customers collection. Returns NotFound if there is no such customer. Supports conditional GET.")]
public Customer GetCustomer(string id)
{
    lock (writeLock)
    {
        // return NotFound if there is no item with the specified id.
        object itemEtag = customerEtags[id];
        if (itemEtag == null)
        {
            throw new WebFaultException(HttpStatusCode.NotFound);
        }
  
        // return NotModified if the client did a conditional GET and the customer item has not changed
        // since when the client last retrieved it
        WebOperationContext.Current.IncomingRequest.CheckConditionalRetrieve((long)itemEtag);
        Customer result = this.customers[id] as Customer;

        // set the customer etag before returning the result
        WebOperationContext.Current.OutgoingResponse.SetETag((long)itemEtag);
        return result;
    }
}

Biztonsági szempontok

Az engedélyezést igénylő kéréseknek nem szabad gyorsítótárazniuk a válaszaikat, mert az engedélyezés nem történik meg a válasz gyorsítótárból való kézbesítésekor. Az ilyen válaszok gyorsítótárazása súlyos biztonsági rést jelentene. Az engedélyezést igénylő kérések általában felhasználóspecifikus adatokat biztosítanak, ezért a kiszolgálóoldali gyorsítótárazás nem is előnyös. Ilyen helyzetekben az ügyféloldali gyorsítótárazás vagy egyszerűen egyáltalán nem gyorsítótárazás megfelelőbb lesz.