blog.pagesd.info

Dans MVC Music Store, la gestion du règlement est composée de deux parties : renseigner l'adresse et le mode de paiement puis terminer la commande.

Le code pour gérer l'adresse et le mode de paiement dans la version d'origine :

Et ce même code correspondant à la version portée sous Raven :

Comme vous pouvez le constater, ils sont presque identiques. Mais le code pour Raven n'est pas tout à fait complet.

Si vous vous souvenez, nous avions décidé de stocker une propriété CountSold dans le document Album, pour pouvoir plus facilement faire un classement en fonction de ce compteur. Il nous reste donc à réaliser l'incrémentation de ce compteur, ce que j'ai codé immédiatement après l'appel à CreateOrder :

Le truc essentiel dans ce code, c'est que nous avons chargé tous les documents albums en une seule requête. Et lorsque nous sauvegardons, Raven va effectuer un seul appel (batch) au serveur.

Et maintenant, pour être tout à fait complet, voyons ce que donnait la méthode Complete() :

Et dans la nouvelle version sous Raven :

Je pense qu'arrivé à ce point, vous êtes en mesure de comprendre comment fonctionne les deux versions.

Mon prochain billet concernera la partie administration de l'application.

La classe ShoppingCart de MVC Music Store est ma tête à claque du moment. C'est plus fort que moi.

Vous pouvez admirer à quoi elle ressemble dans l'illustration de droite. Le souci avec elle, c'est que c'est le genre de code qui fait l'amalgame entre deux responsabilités différentes :

• Les opérations au sujet du panier
  • GetCart
  • GetCartId
  • GetCartItems
  • GetCount
• Les traitements du contenu du panier
  • AddToCart
  • CreateOrder
  • EmptyCart
  • MigrateCart
  • RemoveFromCart

Vous avez sans doute remarqué que toutes les opérations au sujet du panier correspondent à des fonctions get. Tous les traitements du contenu du panier sont relatifs aux articles du panier, ils représentent la logique métier du panier et sa raison d'être. Les opérations Get ne sont pas rattachées aux articles du panier, elles dépendent d'un autre genre d'objet qui gère les instances de paniers.

Dans la plupart des applications, cet objet s'appellerait un Repository. Je ne suis pas certain que cela nous soit utile dans le cas présent. Si on étudie les méthodes Get de plus près, on se rend compte que la seule justification de leur existence vient du fait que l'on a choisi de stocker uniquement les articles du panier. Comme il n'existe pas d'entité panier, nous sommes obligé d'effectuer des requêtes explicites pour obtenir ces données.

Avec Raven, nous procèderons différemment, ce qui fait que la seule chose dont nous devrions avoir besoin est GetCart() et peut-être GetCartId().

Voici donc à quoi un document panier ressemblera :

Ce qui donnera en tant qu'entité :

La méthode GetTotal a été remplacée par une propriété Total. Contrairement à la méthode GetTotal qui va générer un accès à la base de données, cette propriété fonctionne uniquement à partir des données en mémoire. Cela constitue une autre différence majeure de Raven par rapport à une autre solution ORM : on ne va pas faire de lazy loading. C'est quelque chose d'inhérent aux bases de données documents : les données du modèle ont rarement besoin de parcourir d'autres données en dehors de leur propre document. Parcourir le document avec Raven ne risque pas de provoquer du lazy loading ou de nous entrainer dans de redoutables problèmes de type SELECT N+1.

Et maintenant, occupons nous de gérer les opérations au sujet du panier. Les plus importantes sont GetCartId et GetCart. Je considère que ces méthodes n'ont rien à faire là. J'ai donc créé une nouvelle classe ShoppingCartFinder qui ressemble à ceci :

Vous pouvez voir que nous n'exposons plus la méthode GetCartId. Il s'agit d'un élément interne qui n'a pas à être connu des clients de cette classe. La méthode SetShoppingCartId() est là parce que nous devons gérer l'initialisation de l'identifiant d'un panier étant donné que nous voulons gérer le transfert d'un panier (lorsqu'un utilisateur anonyme se connecte). Comme nous n'avons pas besoin des autres méthodes, je les ai supprimées.

Continuons avec les traitements du contenu du panier. Pour mémoire, voici la méthode AddToCart() d'origine :

Et voici cette méthode portée sous Raven :

Le code pour Raven fonctionne entièrement en mémoire et sans se soucier de tout l'aspect persistance. Le code d'origine se charge explicitement de tout ce qui est persistance. Ce n'est pas un problème en soi, mais ce n'est pas le bon endroit pour s'occuper de persistance.

Passons à RemoveFromCart() :

Vous pouvez voir que sa taille diminue de façon très significative et qu'une fois encore, il ne s'agit plus que d'un traitement en mémoire. La méthode EmptyCart() n'est pas implémentée puisqu'avec Raven cela correspond juste à un Lines.Clear().

Un truc intéressant à voir, c'est que l'ancienne implémentation de EmptyCart() aurait généré N requêtes (N étant le nombre d'articles dans le panier) alors qu'avec Raven cela engendre une seule requête.

La méthode CreateOrder() d'origine :

Et celle pour Raven pour laquelle il n'y a pas grand chose à dire si ce n'est que l'ancien code exacuterait N * 2 requêtes là où le code pour Raven continuera de se contenter d'une seule requête :-)

MigrateCart() est plus intéressant parce que son implémentation est complètement différente. Dans le code d'origine, on met à jour tous les articles du panier un par un :

Avec Raven, nous allons faire quelque chose de radicalement différent :

L'identifiant du panier sert pour définir la clé du document et donc, en initialisant cet identifiant (soit avec le nom de l'utilisateur soit avec une valeur stockée en session), nous pouvons charger le panier à l'aide d'une méthode Load (sur la clé primaire pour faire une comparaison avec le monde des bases relationnelles). Le transfert du panier est alors une opération toute simple. Tout ce que vous avez à faire, c'est de changer sa clé. Etant donné que Raven ne permet pas de la renommer, nous allons faire une suppression puis une insertion qui s'exécuteront dans la même transaction.

Le code pour appeler la méthode MigrateCart() est le suivant :

Etant donné que SaveChanges est atomique et transactionnel, cela a le même effet que de faire un Rename.

Et c'est tout pour le panier. Je consacrerai mon prochain billet au contrôleur ShoppingCartController qui utilise cette classe.

Je me suis rendu compte qu'à cause d'une faute de frappe lorsque j'avais fait la reprise des données, les informations sur l'artiste étaient enregistrées en tant que "Arist" au lieu de "Artist". Cela va me donner l'occasion de montrer comment faire une migration du modèle de données un peu plus sophistiquée.

using (var documentStore = new DocumentStore { Url = "http://localhost:8080" })
{
    documentStore.Initialise();

    var count = 0;

    do
    {
        var queryResult = documentStore.DatabaseCommands.Query("Raven/DocumentsByEntityName", new IndexQuery
        {
            Query = "Tag:`Albums`",
            PageSize = 128,
            Start = count
        });


        if (queryResult.Results.Length == 0)
            break;

        count += queryResult.Results.Length;
        var cmds = new List<ICommandData>();
        foreach (var result in queryResult.Results)
        {
            var arist = result.Value<JObject>("Arist");
            if(arist == null)
                continue;
                        
            result["Artist"] = arist;
            result.Remove("Arist");

            cmds.Add(new PutCommandData
            {
                Document = result,
                Metadata = result.Value<JObject>("@metadata"),
                Key = result.Value<JObject>("@metadata").Value<string>("@id"),
            });
        }

        documentStore.DatabaseCommands.Batch(cmds.ToArray());

    } while (true);
    
}

Je ne pense pas que le code soit très compliqué à suivre. Vous pouvez voir comment on peut manipuler les documents en travaillant directement au niveau du document JSON plutôt que de passer par une couche objet.

Comme je l'ai indiqué dans le billet précédent, nous pouvons solutionner le problème de la méthode GetTopSellingAlbums() grâce au map/reduce, mais cela n'est pas vraiment la bonne façon de faire les choses. Le problème en procédant de la sorte (en plus des regards effrayés et des cris de détresse que vous suscitez dès que vous mentionnez cette solution), c'est qu'on essaie de résoudre le problème selon une logique relationnelle. Et d'ailleurs, la solution précédente est quasiment identique à la façon dont une base de données relationnelle pourrait traiter ce genre de requête. Voyons plutôt quelle serait l'approche d'une base de données documents pour résoudre ce genre de problème.

La réponse est évidente à trouver : rappelez-vous que les documents sont indépendants et réfléchissez à nouveau à la question. Ce que nous cherchons à savoir, c'est quels sont les albums les plus vendus. Si nous ajoutions une propriété CountSold à l'album, cela deviendrait immédiatement bien plus simple de répondre à cette question. Et pour cela, il nous suffit de mettre à jour les différents albums qui font parti de la commande lorsque celle-ci est validée. C'est quelque chose de tout à fait acceptable et ce genre d'opération est couramment effectuée, y compris avec des bases de données SQL.

Pour l'instant, laissons de côté la façon de créer la propriété CountSold et de l'initialiser avec les bonnes valeurs (je verrai ça dans mon prochain billet). Nous supposerons donc que c'est déjà fait et qu'il ne nous reste plus qu'à trouver comment résoudre le problème de notre méthode GetTopSellingAlbums().

Et bien, c'est plutôt simple. Tout ce que nous avons à faire, c'est de définir un index sur CountSold.

// AlbumsByCountSold
from album in docs.Albums
select new { album.CountSold };

Avec ça, nous pouvons implémenter la fonction GetTopSellingAlbums() de la façon suivante :

C'est fait : simple, efficace et même élégant (même si c'est moi qui le dit).

Voici le code nécessaire pour lire les données dans la base de données de MVC Music Store et les transformer en documents comme attendu par Raven :

using (var documentStore = new DocumentStore { Url = "http://localhost:8080" })
{
    documentStore.Initialise();
    using (var session = documentStore.OpenSession())
    {
        foreach (var album in storeDB.Albums.Include("Artist").Include("Genre"))
        {
            session.Store(new
            {
                Id = "albums/" + album.AlbumId,
                album.AlbumArtUrl,
                Arist = new { album.Artist.Name, Id = "artists/" + album.Artist.ArtistId },
                Genre = new { album.Genre.Name, Id = "genres/" + album.Genre.GenreId },
                album.Price,
                album.Title,
            });
        }
        foreach (var genre in storeDB.Genres)
        {
            session.Store(new
            {
                genre.Description,
                genre.Name,
                Id = "genres/" + genre.GenreId
            });
        }
        session.SaveChanges();
    }
}

Comme vous pouvez le constater, c'est plutôt simple. Et même si c'est moi qui le dit, plutôt bien foutu.

J'ai utilisé des types anonymes parce que je me contente de migrer les données. Je ne m'occupe pas vraiment de savoir comment gérer les types pour l'instant.

Le tutoriel "MVC Music Store" est venu à point nommé pour moi. Je souhaitais faire une application de démonstration pour Raven DB et le fait que quelqu'un d'autre ait déjà fait tout le travail ingrat (l'interface utilisateur :) à ma place et que je n'ai plus qu'à refaire l'accès aux données est une situation rêvée. Mon objectif est de ne rien toucher du tout au Javascript ou au code HTML et de me contenter de remplacer les contrôleurs. Ca devrait être intéressant de voir si je peux y arriver.

Le modèle de base de données dans le tutoriel d'origine est le suivant :

On peut déjà remarquer deux ou trois choses intéressantes dans ce schéma :

• Il serait plus correct que la table Cart soit nommée CartLineItem puisqu'elle stocke une ligne par article dans le panier
  • CartId n'est pas une clé étrangère, mais référence le nom de l'utilisateur ou l'identifiant de la session
• La table Artist gère uniquement le nom de l'artiste et rien d'autre.

A partir de ces informations, je considère que le modèle de données suivant devrait convenir.

Albums

• Le document Album contient à la fois une référence pour le Genre et pour le libellé du genre. Cela nous permet d'afficher l'album sans avoir à référencer le document Genre.
• Et pour les mêmes raisons, le document Album contient aussi le nom et l'identifiant de l'artiste.
• Il n'y a pas un ensemble de documents Artists dans la base de données. Nous ne gérons aucune information sur les artistes, si ce n'est leur nom, et je ne vois donc pas de raison pour définir un document Artist pour l'instant.

Genre

Le document Genre est la réplique exacte de la table Genre, rien d'extraordinaire à ce niveau.

Cart

Le document Cart suit un format de document plutôt classique. Nous avons un simple document qui contient un tableau d'éléments là où le modèle de données relationnel contient un ensemble de lignes. Vous pouvez voir que le UserIdentifier nous sert pour stocker l'identifiant de l'utilisateur ou celui de la session pour le panier.

Orders

Order constitue une autre document plutôt standard. Nous regroupons toutes les information de la commande dans un simple document et nous stockons les informations liées à celle-ci (Address) dans un noeud spécifique.

Artist

Il n'y a pas de document Artist.

Pourquoi un document pour Genre et pas pour Artist ?

Pour la bonne raison que l'application va faire quelque chose avec les Genres (en plus d'afficher leur description) alors que la seule chose que l'on fait avec les Artistes est d'afficher leur nom dans la cadre d'un album. Pour l'instant, je considère que Artist fait partie intégrante de Album et qu'il n'y a donc pas à définir un document spécifique pour lui. La seule raison au fait qu'il existe un identifiant artiste en plus du nom est que je suppose (d'après les données) que la source pour les artistes est un système externe qui fait quelque chose d'un peu plus utile que simplement stocker le nom de l'artiste.

Nous n'avons fait que la moitié du travail à faire. Nous avons défini le modèle de données, maintenant nous devons étudier comment il sera utilisé dans un contexte plus large et lui ajouter le modèle de requête en utilisant des index. Nous verrons cela dans un prochain billet.