.NET on MemoryLeak

Utiliser Couchbase comme serveur de cache

Fri, 11 Apr 2014 13:13:00 +0000

Dernièrement, je vous présentais une façon simple d’utiliser le cache dans vos applications .NET

Cependant cette solution possède plusieurs inconvénients. En voici quelque uns :

Le cache est lié au processus système de votre application (executable / IIS etc…). Si votre programme plante ou est fermé, vous perdez votre cache
Si vos besoins en mémoire augmentent, cette solution n’est pas scalable
Rien n’est mis a disposition pour monitorer votre cache
Vous n’avez pas d’interface de gestion du cache (augmentation de la mémoire allouée etc…)

Poor man's cache

Fri, 04 Apr 2014 15:10:00 +0000

Depuis la version 4 du framework .NET, la gestion d’un cache est profondement encrée dans l’adn de notre framework.

Il devient alors extrêmement facile de stocker en mémoire à peu près n’importe quoi.

Je vous livre dans ce court billet, une implémentation extrêmement simple que j’utilise souvent dans mes projets.

Commençons par définir une interface, qui nous permettra [d’injecter](http://blog.ploeh.dk/tags.html#Dependency Injection-ref) notre cache manager un peu partout :

public interface ICacheManager
{
 T GetOrInsert(string key, Func callback) where T : class;
}

et finalement voici une implémentation extra simple de notre cache manager

EntityFramework.Patterns 0.8 est compatible EF 6

Sun, 17 Nov 2013 21:01:00 +0000

Ça faisait longtemps que je n’avais pas remis les mains dans ce projet, plus d’un an pour être exact. Le passage à Entity Framework 5 n’avait pas posé de soucis car aucun breaking changes dans l’API n’avait bloqué l’utilisation de la librairie. C’est surement ce qui explique le nombre “plutôt important” (7500) download sur nuget gallery.

Mais avec EF 6 c’est une autre histoire, tout un tas de nouvelles fonctionnalités très sympa, mais aussi une api qui a pas mal bougé… ainsi plusieurs utilisateurs sur codeplex, m’ont tout naturellement contacté pour me demander de mettre à jour EntityFramework.Patterns.

SSIS vs TPL.Dataflow

Thu, 31 Oct 2013 17:18:00 +0000

Il y a quelques jours je tweetais de joie, après être tombé sur la msdn concernant TPL.Dataflow

L’API propose un système de pipeline que l’on peut aisément imaginer utiliser dans un process d’ETL.

Ni une ni deux, je m’imagine délaisser SSII lors de mes prochaines alims de base de données et enfin pouvoir unit tester mon ETL.

L’accueil fait par mes collègues purement BI fut plutôt frileux… n’est ce pas David :)