Ca vous est déjà arrivé de déployer en prod une nouvelle version de votre application et d'oublier de passer la migration EF à la mano ? Eh ben moi aussi. On se retrouve alors à executer le script sql de migration en urgence, en espérant que tout se passera bien. Bref, c'est la panique à bord!

Histoire de ne plus revivre cette situation inconfortable, on est tenté d'avoir recours à la migration EF par le code. Ainsi, on est certains qu'a chaque exécution de notre app, la migration sera effectuée si le schéma de la BDD n'est pas à jour. Le problème, c'est que si la migration se passe mal, on se retrouve à nouveau avec une application plantée en production → retour à la case départ.

Et si on pouvait appliquer la migration EF par le code, mais pendant le déploiement. Après tout, avec la cli dotnet, il est tout à fait possible d'exécuter une migration. Alors pourquoi ne pas le faire à travers un script powershell durant le deploy ? Si vous utilisez Octopus comme chez Younited Credit, alors c'est possible !

Migration avec la dotnet cli

Supposons que vous ayez découpé classiquement votre application en couche de manière à avoir votre startup project et votre DAL séparés, par exemple :

• MyCompany.AppOfTheFuture : application console en .NET Core
• MyCompany.AppOfTheFuture.DAL : Votre Data Access Layer, celle qui contient vos repositories Entity Framework, votre DbContext et votre code de migration

Afin d'exécuter une migration avec la cli .NET Core, on peut utiliser la commande suivante depuis PowerShell :

dotnet.exe exec `
    --depsfile "MyCompany.AppOfTheFuture.deps.json" `
    --runtimeconfig "MyCompany.AppOfTheFuture.runtimeconfig.json" `
    "${env:ProgramFiles}\dotnet\sdk\NuGetFallbackFolder\microsoft.entityframeworkcore.tools\2.1.1\tools\netcoreapp2.0\any\ef.dll" database update `
    --context AppOfTheFutureContext `
    --verbose `
    --no-color `
    --prefix-output `
    --assembly "MyCompany.AppOfTheFuture.DataAccess.dll" `
    --startup-assembly "MyCompany.AppOfTheFuture.dll" `
    --project-dir "." `
    --root-namespace MyCompany.AppOfTheFuture.DataAccess

La ressource ef.dll peut être considérée comme l'équivalent de migrate.exe pour EF6. C'est la dedans que se trouve le code qui sera exécuté pour appliquer la migration en base de donnée. Il est important de renseigner le chemin correct de la DLL selon la version de .Net core que vous avez installé.

Les paramètres importants de la commande sont :

• ef.dll database update : définit le type d'opération à appliquer sur la BDD. Parmis les options possibles, il existe également la commande create afin d'initialiser une BDD.
• --context AppOfTheFutureContext Définit la classe de contexte EF
• --assembly "MyCompany.AppOfTheFuture.DataAccess.dll" Définit le nom de l'assembly contenant la classe contexte
• --startup-assembly "MyCompany.AppOfTheFuture.dll" Définit le nom de votre startup project. En outre, il s'agira vraisemblablement du projet où se trouve votre appsettings.json et la chaîne de connexion à la BDD.

A la suite de l'exécution de cette commande, si tout s'est bien passé, votre BDD doit être à jour et aligné sur la dernière migration.

Intégration de la migration dans Octopus

Maintenant que nous savons jouer une migration en CLI, la migration depuis Octopus n'est plus très compliquée à mettre en place. En effet, il suffit de jouer un bout de script PowerShell pendant la tâche de déploiement et c'est joué !

A titre d'exemple, on va se baser sur le déploiement d'une webapp Azure et donc du template Octopus Deploy an Azure Web App :

Dans ce template, il est possible de renseigner un script PowerShell à exécuter en Pre-Deploy/Deploy/Post-Deploy. On va s'intéresser à la mise en place du script pendant le deploy. Si on le fait trop tôt, on ne pourra pas profiter de la valorisation des variables dans notre appsettings.json.

Il nous suffit juste de recopier la ligne de commande précédemment mentionnée dans la section Features / Configuration Scripts et c'est tout bon :

L'intérêt de cette approche est de mettre en évidence un problème de base de données rapidement, et surtout avant que votre webapp soit en ligne. Fail Fast! Dans notre cas, si la migration échoue dans Octopus, alors ce dernier ne poursuivra pas le déploiement.

Auteurs

Cet article a été rédigé avec mon ami et collègue Anthony Hocquet. Vous le retrouverez sur son nouveau blog que je vous incite à suivre tant les futurs articles sont prometteurs !

Commençons par ce qui fait mal. Je dois avouer que ce blog post fait suite à un fail.
Dans cette version 0.2 de Blazor, il y a pas mal de code glue à produire pour pouvoir appeler une fonction javascript à partir de votre code C#.

Cela se passe en 2 étapes :

• A partir de votre code javascript, il faut enregistrer une fonction dans le contexte de Blazor.

Blazor.registerFunction('DisplayAlert', (data) => {
        alert(data);
        return true;
});

• Quand vous souhaitez faire appel à cette fonction on utilisera alors un code de ce type, cette fois ci dans votre code C#.

RegisteredFunction.Invoke<bool>("DisplayAlert", text);

On remarque que tout ca fonctionne à base de magic strings (le nom de la methode), que les functions sont obligées de retourner une valeur (void n'est pas prit en compte pour l'instant), et puis ce RegisteredFunction.Invoke c'est vraiment pas super sexy.

Du coup je m'étais dis, ca pourrait être sympa d'au moins cacher RegisteredFunction.Invoke, et voici comment j'imaginais la chose.

On pourrait commencer par définir l'ensemble des fonctions js dans une interface C#, un peu comme ca :

public interface IAlerter
{
    bool DisplayAlert(string text);
}

Le choix de l'interface n'est pas complétement anodin, Retyped propose un grand nombre de librairies js exposées sous forme d'interface C#, ce qui nous ouvre la porte a plein de possibilités.

Pour en revenir à notre interface IAlerter, on peut l'injectée dans notre component Blazor à l'aide de l'attribut ***[Inject]***, comme ceci.

public class Interoper : BlazorComponent
{
    [Inject]
    protected IAlerter Alerter { get; set; }

    public string Sometext { get; set; }

    public virtual void Say()
    {
        Alerter.DisplayAlert(Sometext);
    }
}

Et finalement il nous ne nous manque qu'un petit helper magique produisant une implémentation de l'interface IAlerter se chargeant de faire les RegisteredFunction.Invoke qui vont bien. Un truc qui pourrait ressembler à ca :

var alerter = Substitute.For<IAlerter>();
alerter.DisplayAlert(Arg.Any<string>())
       .Returns(info => RegisteredFunction.Invoke<bool>("DisplayAlert", info.ArgAt<string>(0)));

Evidemment ici, je vous présente la version naïve qui ne fonctionne que pour notre interface, mais avec un peu de reflection on peut rendre cela générique sans trop de mal.

Le fail est sous vos yeux, si vous executez ça dans la console de votre navigateur vous aller voir une très belle exception avec un stack de 3 pieds de long. (@Charly, elle est pour toi celle-ci)

Une grosse PlatformNotSupportedException! Impossible d' utiliser l'api System.Reflection.Emit avec Mono Webassembly. C'est emmerdant, mais en y reflechissant bien, c'est pas déconnant si on veut maintenir un framework pas trop fat dans le navigateur.

L'expérimentation sur ce point précis s'arrete donc la, mais tout n'est pas à jeter.
Je retiens de cette aventure l'organisation du code. Une interface décrivant l'interop javascript, qui sera injectée dans les BlazorComponent, et une implémentation concrète de l'interface, comme ceci.

public class Alerter : IAlerter
{
    public bool DisplayAlert(string text)
    {
        return RegisteredFunction.Invoke<bool>("say", text);
    }
}

On est pas allé aussi loin que je ne l'aurais espéré, mais qui sait dans une prochaine version de Blazor cela sera peut etre possible.

Depuis quelque temps dans la communauté .NET on parle fait pas mal de marketing autour de Blazor. Je ne vais pas vous présenter cette nouvelle techno... si vous etes ici, c'est que vous connaissez déjà :).

Une des premières choses qui m'a embété fut de voir dans les articles de présentation un mélange sans vergogne du code html et du code .NET wrappé dans la section @functions

je parle de ca :

@using System
@page "/guid"


    <h1>Guid Generator</h1>

    <input type="text" value="@generatedGuid"/><button type="button" @onclick(Generate)>Generate!</button>

    @functions {

        string generatedGuid = string.Empty;

        private void Generate()
        {
            generatedGuid = Guid.NewGuid().ToString();
        }
    }

Evidemment, ici le code est extremement simple, mais dans la vraie vie j'vous le donne dans le mille on aurait envie de faire des tests unitaires de notre code C#.

Je vous propose donc cette facon de faire. On va créer un classe qui hérite de BlazorComponent et on y mettra notre code métier.

Commençons par créér une classe qui contiendra notre code behind

using System;
using Microsoft.AspNetCore.Blazor.Components;

namespace OwnBlazor.Pages
{
    public class GuidGenerator : BlazorComponent
    {
        public string GeneratedGuid { get; set; }

        public void Generate()
        {
            GeneratedGuid = Guid.NewGuid().ToString();
        }
    }
}

la seule chose qu'il faut noter ici, c'est que notre classe hérite de BlazorComponent

Passons à notre vue qui est maintenant beaucoup plus propre.

@page "/guid2"
@inherits OwnBlazor.Pages.GuidGenerator

    <h1>Guid Generator</h1>

    <input type="text" value="@GeneratedGuid"/><button type="button" @onclick(Generate)>Generate</button>

Dans la vue on spécifiera que l'on hérite de notre classe GuidGenerator précédement créée.

Voila, c'est quand même un peu plus propre et surtout pn peut facilement tester notre code C#.

Il y a tout juste quelques jours, on pair programmait avec Anthony sur un projet. Nous nous sommes retrouvés a vouloir combiner au runtime des Expressions trees en fonction de parametres évalués au runtime.

En gros on avait envie d'écrire un truc du genre

Expression<Func<Person, bool>> predicate = x => x.Id > 1;

puis un peu plus loin

predicate += x => x.Name.Length < 6;

Ne cherchez pas à compiler ca, le compilo risque de se rebeller.

On était un peu pris par le temps, du coup on a fait un simple. Néanmoins je profite de cet espace pour partager avec vous une facon de faire pour combiner des Expressions et faire du code un peu plus sexy

Pour faire plaisir à maitre Etienne on va travailler a base de tests unitaires.

Commençons par la version naïve; En cherchant un peu sur la msdn on tombera facilement sur Expression.AndAlso permettant de créer une nouvelle expression qui combine deux Expressions left et right

        [Fact]
        public void SimpleCombining_Fails()
        {
            // Arrange
            Expression<Func<Person, bool>> firstPredicate = x => x.Id > 1;
            Expression<Func<Person, bool>> secondPredicate = x => x.Name.Length < 6;
            
            Expression binaryexp = Expression.AndAlso(firstPredicate.Body, secondPredicate.Body);
            ParameterExpression[] parameters = {
                Expression.Parameter(typeof(Person), firstPredicate.Parameters.First().Name)
            };
            
            Expression<Func<Person, bool>> lambda = Expression.Lambda<Func<Person, bool>>(binaryexp, parameters);
            
            // Act
            Action filter = () => {
                var combinedPredicate = lambda.Compile();
                var result = _persons.Where(combinedPredicate);
            };

            // Assert
            Assert.Throws<InvalidOperationException>(() => filter());
        }

On commence par définir nos deux prédicats (left & right) que l'on combine dans une expression binaire AndAlso (et logique) en utilisant comme paramètre générique T le paramètre utilisé dans la premiere expression initiale.
On essaye par la suite d'utiliser la lambda créée pour l'occasion dans une instruction Where que vous connaissez tous en Linq.

Bon, j'avais déjà vendu la méche en disant que c'était une version naïve; effectivement a l'execution vous allez avoir une InvalidOperationException

System.InvalidOperationException: 'variable 'x' of type 'AndOrExpressions.Person' referenced from scope '', but it is not defined'

Pour faire simple, dans nos deux expressions initiales, le paramètre x bien qu'il se nomme de la même maniere et soit du même type, il ne s'agit pas du meme objet. x est donc inconnu dans la seconde expression.

Etant donné que les Expressions sont des objets immutables il va nous falloir un moyen de créer/réécrire une expression donnée.

C'est pour ce genre de cas qu'MS a mis à notre disposition la classe ExpressionVisitor. Celle-ci nous permet de traverser l'expression tree et d'apporter des modifications. Rappelez vous que chaque modification produira une nouvelle expression, c'est le principe même de l'immutabilité.

Ok, commencons par créer une visiteur qui remplacera un paramètre T par un autre passé en paramètre.

public class ReplaceExpressionVisitor : ExpressionVisitor
    {
        private readonly Expression _searched;
        private readonly Expression _replacement;

        public ReplaceExpressionVisitor(Expression searched, Expression replacement)
        {
            _searched = searched;
            _replacement = replacement;
        }

        public override Expression Visit(Expression node)
        {
            if (node == _searched)
            {
                return _replacement;
            }   
            return base.Visit(node);
        }
    }

Simple, non?

Du coup si on réécrivait notre test de la facon suivante en imaginant une methode And qui permet de combiner des Expressions

[Fact]
        public void ReplacingType_Succeed()
        {
            // Arrange
            Expression<Func<Person, bool>> firstPredicate = x => x.Id > 1;
            Expression<Func<Person, bool>> secondPredicate = x => x.Name.Length < 6;

            Func<Person, bool> combinedPredicate = firstPredicate.And(secondPredicate);
            
            // Act
            var result = _persons.Where(combinedPredicate);

            // Assert
            Assert.Collection(result, people => Assert.Equal(people, Anto));
        }

Il ne nous reste qu'à définir une methode d'extension qui répond a cette signature, comme ceci :

public static class ExpressionsExtensions
    {
        public static Func<T, bool> And<T>(this Expression<Func<T, bool>> firstOperand, Expression<Func<T, bool>> secondOperand)
        {
            var replacement = Expression.Parameter(typeof(T));

            var leftVisitor = new ReplaceExpressionVisitor(firstOperand.Parameters[0], replacement);
            var left = leftVisitor.Visit(firstOperand.Body);

            var rightVisitor = new ReplaceExpressionVisitor(secondOperand.Parameters[0], replacement);
            var right = rightVisitor.Visit(secondOperand.Body);

            return Expression.Lambda<Func<T, bool>>(Expression.AndAlso(left, right), replacement)
                             .Compile();
        }
    }

Cette methode va combiner avec Expression.AndAlso nos deux expressions initiales, mais cette fois ci on aura prit soin de les réécrire en utilisant le même paramètre générique. Et évidemment cette fois-ci, le test est vert :)

J'ai passé 8 ans la-bas, sur blogger. Si je me souviens bien c'est Francois qui m'avais recommandé cette plateforme. Puis le temps à passé, François comme beaucoup d'autres ont bougé vers d'autres horizons, wordpress par exemple.

Pas moi... un peu par flemme, faut bien le dire.

Parfois l'idée et l'envie de pondre un article est la, mais compliqué de le faire dans le train car faut etre connecté sur blogger.com pour pouvoir écrire. D'autres problématiques se font sentir, ou stocker les images/screenshots etc...

Bref, il etait temps de demenager. Mais pour aller ou?

J'en ai parlé à mes collègues chez mon client actuel. J'voulais un truc light, facile à heberger, avec lequel je pouvais travailler en mode déconnecté. On a parlé de Ghost, de Jekyll, et puis des modes d'hébergement. Et la ca a fait tilt quand Anthony m'a rappelé qu'il y avait les github pages. En deux mots, un repository git qui est exposé comme un site web.
Merci encore pour le brainstorming mon grand!

D'ailleurs dans un prochain billet, je détaillerai la solution technique derrière ce blog, et comment j'ai rapatrié tous les posts depuis mon ancienne plateforme.
Ho, j'oubliais, github pages est si smart que j'ai même pu investir dans un nom de domaine (deux en réalité) et l'affecter à ce repository git.

Me revoilà donc, sous une nouvelle forme visuelle mais comme avant, pour partager mes pérégrinations autours des technos Microsoft.

L’IOT, on en parle partout, de plus en plus ; évidemment l’univers Microsoft n’est pas en retrait sur ce domaine avec la mise à disposition de Windows 10 sur le Raspberry ou encore le MinnowBoard MAX

Vous trouverez pas mal de blog post autour du raspberry… je vais donc plutôt vous présenter comment vous lancer dans le développement .NET embarqu& sur cette magnifique plateforme qu’est le BeagleBone Black (BBB). Au travers de cet article je vous propose d’étudier les différentes étapes à réaliser pour pouvoir lancer votre premier « Hello World » embarqué.

Tout d’abord il n’y a pas de Windows 10 sur le BBB, en tout cas pour l’instant, mais très honnêtement l’installation d’Ubuntu que je vous propose est à la portée de tous.

Matériel nécessaire

Je commence par un petit coup de pub pour le site AdaFruit ou vous trouverez tout le matos que vous pouvez imaginer pour nos petits joujoux.

Aller Go ! Pour faciliter la visualisation de ce qui se passe sur votre BBB je vous conseille d’investir dans un câble Serial TTL-232 en usb. Sans celui-ci vous devrez attendre que le BeagleBone ai récupéré une IP et vous y connecter (en ssh par exemple) et interagir avec.

Pour brancher le câble prenez comme repère le fil noir qui doit venir se placer sur le pin J1 de votre BBB.

Installez les drivers FTDI pour prendre en compte l’adaptateur usb. Ils se trouvent ici

Finalement en utilisant Putty, configuré comme ci-dessous la console s’affiche enfin sur votre pc.

Si l’idée de brancher un câble Ethernet sur votre BeagleBone vous donne de l’urticaire, je vous conseille ce dongle usb. Il est directement reconnu sous Ubuntu.

Installation d’Ubuntu

Nous allons installer dans la mémoire eMMC la version 14.04 d’Ubuntu spécialement conçue pour la BBC. Après avoir téléchargé le fichier img.xz, il vous faudra le décompresser avec un outil comme 7zip.

L’image ainsi extraite pourra être copiée sur une micro sd avec Win 32 Disk Imager

Lorsque la copie se termine, insérer la micro sd dans le port prévu à cet effet sur la BBB. Tout en appuyant avec votre index sur le bouton « boot » (le plus proche du port Ethernet), alimentez la BeagleBone. Laissez le doigt appuyé jusqu’à ce que les diodes clignotent.

Il faut 5 bonnes minutes pour que l’installation se termine ; mais grâce au câble TTL vous serez aux premières loges pour suivre l’installation.

Mise à jour du Système et installation de mono

Ok, si vous en êtes arrivé là, c’est du tout cuit.

Nous allons commencer par mettre à jour le système grâce package manager APT. A partir de la console tapez les commandes suivantes :

sudo apt-get update sudo apt-get upgrade

Après quelques minutes le système est prêt, on peut passer à Mono. Le runtime devrait être suffisant étant donné que l’on va se contenter d’exécuter des binaires créer sur votre machine de dev. Pour l’installation on tape donc :

sudo apt-get install mono-runtime

Création de l’exécutable et déploiement sur le BBB

Je vous laisse écrire votre premier Hello Beagle World dans Visual Studio ; en créant un projet de type console et en targettant le Framework 4.5;

Une fois compilé, j’ai opté pour un déploiement type « bin-deploy » en utilisant un transfert via PSCP

Une fois PSCP copié, vous pourriez copier le fichier avec une ligne de commande comme celle-ci :

pscp.exe "C: BBB HelloWorldbinDebugHelloWorld.exe" ubuntu@192.168.10.2:/home/ubuntu

Le premier paramètre étant le ficher à transmettre le second l’url de destination au format :

user@hote:/chemin_de_destination

En dessert, après tous ces efforts, nous pouvons enfin exécuter sur le Beagle notre Hello World en tapant :

Mono HelloWorld.exe

Cet article fait partie d’une sérié dédiée à Elasticsearch, reportez vous à l’article sommaire pour accéder facilement aux autres posts.

Kibana est la brique de visualisation qui gravite autour d’Elasticsearch. Voici, quelques exemple de représentations faites avec Kibana :

L’exploration de données et la réalisation de dashboard ne nécessitent aucun code, ce qui permet de donner la main aux fonctionnels ; De plus Kibana et Elastocsearch permettent d’avoir des rapports real time, se mettant à jour à mesure que les données sont stockées.

Pour les lecteurs qui connaissent bien la stack SQL Serveur, on pourrait le comparer à un Report Builder sous stéroïdes et surtout qui tiendrait (mieux) ses promesses de simplicités et d’accessibilité pour les non-techniciens

Je me propose dans ce billet de découvrir ensemble les fonctionnalités de « data discovering » sur un dataset public recensant les accidents corporels de la circulation

Si ces données vous intéressent, je vous invite d’ailleurs à jeter un œil à la très bonne session (video, slides) de Patrice Harel sur le mining avec SSAS et qui s’appui sur le même jeu de données.

Installation

Commençons par l’installation qui comme pour les autres composants de la stack est triviale :
Tout commence évidement par le téléchargement du binaire ici, suivi de la décompression de l’archive.
Si votre instance elasticsearh ne tourne pas sur le même serveur qui hébergera Kibana ou si elle écoute sur un port non standard, il vous faudra modifier le fichier de configuration config/kibana.yml.
Dans mon cas, je ne touche à rien!
Puis à l’aide d’une fenêtre commande, il nous faudra exécuter /bin/kibana après s’être placé dans le répertoire ou a été décompressé l’archive.
Finalement pointons notre navigateur sur l’url http://localhost:5601

Exploration

S’il s’agit de la première fois que vous lancez Kibana, cet écran vous sera présenté, dans lequel il vous faudra choisir un index (équivalent de base de données) ainsi qu’une colonne typée date.
Ce dernier point est extrêmement important, car Kibana part du principe qu’il est naturel pour l’esprit humain et plus facile de découvrir des données lorsqu’elles sont représentées sur une frise.



Dans notre dataset, nous ne disposons malheureusement pas de la date de l’accident, qui aurait été le candidat idéal en tant que « time field ».
Pour l’exemple, nous nous rabattrons sur le champ @timestamp représentant l’instant ou a été inséré l’événement dans notre index.

On se retrouve propulsé dans nos données via l’écran suivant :



On reconnait très vite plusieurs sections dans cette interface :

• La colonne de gauche qui contient les champs à disposition (1).
• Tout en haut (2), une zone de filtre ; n’oublions pas qu’elasticsearch est un moteur de recherche…
• L’indicateur du nombre d’enregistrements après filtrage (3).
• La frise temporelle sur laquelle on regarde les événements (4).
• Finalement la vue tableau de données au centre. Notons que pour l’instant elle nous représente la version brute des données, car nous n’avons pas encore choisit de colonnes à afficher.

Commençons par cliquer sur les barres du graph afin d’effectuer un drilldown au niveau temps.



Instantanément cela nous permet de découvrir la répartition des data dans le temps. Notez, que les clics que nous avons fait sur le graph sont interprétés comme une clause de filtrage, diminuant les événements auxquels on s’intéresse.

Pour avoir un aperçu du contenu des champs, je vous conseille de cliquer sur le nom d'un champ dans la colonne de gauche ; comme ceci :

Les informations et actions présentées ici sont une vraie mine d’or.
En plus d'un premier comptage des données sous-jacentes, on peut par exemple se concentrer sur les événements qui ont eu lieu sur l’A31 en cliquant sur l'icone loupe+. Evidemment, la frise temporelle et les données sont mis à jour.

Maintenant, intéressons nous au champ tbl qui représente le nombre de blessés légers dans un accident.

En cliquant sur « Visualize », on obtient la répartition top 20, sous forme d’histogramme, du nombre de blessés légers sur l’ensemble des événements de la base.



Ici aussi cette visualisation, nous permet d’appréhender rapidement la teneur de nos données.

Finalement jetons un œil, au filtre qui se trouve tout en haut de l’interface de Kibana. Par défaut, vous y trouverez une *. Attention, il n’y a pas ici d’analogie avec SQL, ici l’étoile signifie sans filtre.
Nous pourrions par exemple nous intéresser à une commune en particulier, celle de Cergy par exemple (95002). Il nous suffira pour ce faire de saisir le filtre suivant :

codeinsee:=95002

Ou bien les accidents impliquant plus de 2 morts

ttué:>2

Ou encore les accidents impliquant plus de 2 morts dans l’Oise :

ttué:>2 AND codeinsee [60000 TO 69999]

Voila qui clos ce premier article sur Kibana, en espérant vous avoir donné envie d’essayer ce superbe outil.

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...)
• Vous ne pouvez pas invalider le cache sans arrêter l'application.
• etc...

Bref, vous avez compris, c'est une solution pour démarrer petit.

Aujourd'hui, je voudrais partager avec vous une solution qui répond à tous les manques évoqués plus haut et plus encore.
Couchbase est une base NoSQL Key/Value; la value ayant comme particularité d'être un document json.
Couchbase est issu du mariage heureux de Membase (cache mémoire avec réplication des caches, persistance et interface d’admin Web sexy) et
CouchDB (NoSQL orienté document). Ce qui nous intéresse plus particulièrement aujourd'hui sont les fonctionnalités qui en font un bon serveur de cache.

Installation

Pour l'installer, tout commence par télécharger le setup ici

Je vous passe le scénario d'installation qui a le bon gout de se faire en "Next" > "Next" > "Next"

Passons à la configuration :

Dans la première étape, il vous faudra spécifier l'emplacement des fichiers (base et index) ainsi que la mémoire dévolue à Couchbase.

Un peu plus loin nous allons créer le l'espace qui accueillera les objets que l'on va mettre en cache (bucket).

Quelques instant plus tard vous voila avec un Couchbase flambant neuf sur votre machine.

Note : si la page ne s'ouvre pas automatiquement dans votre browser, la console d'admin de couchbase se trouve a l'adresse suivante : http://localhost:8091/

Implementation

Couchbase dispose d'un très bel écosystème qui gravite autour, et la plateforme .NET ne fait pas exception.
Je me propose d'adapter le cache manager vu dans le précédent article.
Pour rappel nous avions l'interface suivante :

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

Passons à l'implémentation. Il va nous falloir un driver, que l'on peut aisément installer via nuget :

son utilisation est des plus simple, avec des méthodes explicites comme Get() et Store().
Voici une implémentation de cache respectant notre interface basée sur Couchbase.

public class CouchbaseCacheManager : ICacheManager { private readonly CouchbaseClient _client; public CouchebaseCacheManager() { _client = new CouchbaseClient(); } public T GetOrInsert(string key, Func callback) where T : class { T elmnt; try { if (_client.KeyExists(key)) return _client.Get(key); elmnt = callback(); _client.Store(StoreMode.Add, key, elmnt); } catch (Exception) { elmnt = callback(); } return elmnt; } }

Et vous, quel type de cache utilisez vous dans vos projets?