Skip to main content

Cum sa definesti un provider custom pentru cache

.NET 4.0 ne-a adus si posibilitatea de a controla output caching. Pana in momentul acesta puteam sa controlam obiectele la care sa se faca cache. Daca de exemplu avem o actiune la care doream sa facem cache, puteam sa folosim atributul OutputCacheAttribute, prin care puteam defini durata la care sa se faca cache si prin ce parametri acest cache sa difere.
[OutputCache(Duration=20, VaryByParam="none")]
public ActionResult GetItems()
{
// Executa ceva.
}
In momentul in care se face un call spre actiunea GetItems, se verifica daca aceasta exista in cache si daca cache-ul este valid( nu a expirat iar parametri trasmisi prin VaryByParam sunt identici). Daca conditiile sunt indeplinite atunci rezultatul se incarca automat din cache si se trimite mai departe, altfel se executa actiunea GetItems, iar rezultatul se salveaza in cache.
In cazul in care dorim sa definim un provider propiu pentru output cache este nevoie sa scriem o clasa ce sa mosteneasca din OutputCacheProvider.
    public abstract class OutputCacheProvider : ProviderBase
{
public abstract object Get(string key);
public abstract object Add(string key, object entry, DateTime utcExpiry);
public abstract void Set(string key, object entry, DateTime utcExpiry);
public abstract void Remove(string key);
}
Prin intermediul metodelor care ne sunt puse la dispozitie, putem sa controlam provider-ul in totalitate.
In web.config este este nevoie sa specificam ce fel de output cache sa se foloseasca:
<caching>
<outputCache defaultProvider="NameOutPutCache">
<providers>
<add name="NameOutPutCache"
type="FullLocationOfOutputCacheImplementation" />
</providers>
</outputCache>
</caching>

Pentru a vedea un exemplu de implementare puteti sa va uitati aici: http://galratner.com/blogs/net/archive/2010/06/06/write-your-own-outputcacheprovider.aspx
Mai jos puteti sa gasiti un exemplu de outputcach provider pentru MongoDb:
 public class MongoDbOutputCacheProvider : OutputCacheProvider, IDisposable
{
readonly Mongo _mongo;
readonly IMongoCollection<CacheItem> _cacheItems;

public MongoDbOutputCacheProvider()
{
// Initializare coneciune la MongoDb
_mongo = new Mongo();
_mongo.Connect();

var store = _mongo.GetDatabase("OutputCacheProviderDB");
_cacheItems = store.GetCollection<CacheItem>();
}

public override object Get(string key)
{
// Se cauta elementul cu cheia dorita.
var cacheItem = _cacheItems.FindOne(new { _id = key });

//Se deserializeaza elementul gasit.
if (cacheItem != null) {
if (cacheItem.Expiration.ToUniversalTime() <= DateTime.UtcNow) {
_cacheItems.Remove(cacheItem);
} else {
return Deserialize(cacheItem.Item);
}
}

return null;
}

public override object Add(string key, object entry, DateTime utcExpiry)
{

if (utcExpiry == DateTime.MaxValue)
{
utcExpiry = DateTime.UtcNow.AddMinutes(5);
}

// Se adauga elementul in baza de date.
_cacheItems.Insert(new CacheItem
{
Id = key,
Item = Serialize(entry),
Expiration = utcExpiry
});

return entry;
}

public override void Set(string key, object entry, DateTime utcExpiry)
{
var item = _cacheItems.FindOne(new { _id = key });

if (item != null)
{
// In cazul in care elementul deja exista se face update la informatii.
item.Item = Serialize(entry);
item.Expiration = utcExpiry;
_cacheItems.Save(item);
}
else
{
// Se insereaza un element nou.
_cacheItems.Insert(new CacheItem
{
Id = key,
Item = Serialize(entry),
Expiration = utcExpiry
});
}
}

public override void Remove(string key)
{
// Se elimina din MongoDb.
_cacheItems.Remove(new { _id = key });
}

private static byte[] Serialize(object entry)
{
var formatter = new BinaryFormatter();
var stream = new MemoryStream();
formatter.Serialize(stream, entry);

return stream.ToArray();
}

private static object Deserialize(byte[] serializedEntry)
{
var formatter = new BinaryFormatter();
var stream = new MemoryStream(serializedEntry);

return formatter.Deserialize(stream);
}

public void Dispose()
{
_mongo.Disconnect();
_mongo.Dispose();
}
}

Implementarea completa se poate gasi aici:
http://archive.msdn.microsoft.com/mag201103OutputCache/Release/ProjectReleases.aspx?ReleaseId=5514

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too