Ce billet est le second d’une série sur les techniques d’optimisation du temps de chargement d’une application ASP.NET MVC. Le premier article sur la compression et la minification du CSS et JavaScript peut être consulté sur cette page.

Les requêtes des utilisateurs sur une page d’un site Web qu’il soit statistique ou dynamique engendre couramment le chargement de plusieurs éléments et de nombreuses opérations (chargement des images, CSS, JavaScript, données depuis une en base de données, etc.). Imaginez un intervalle de temps pendant lequel près de 100 requêtes sont effectuées sur votre site, et que durant cette période, le même contenu est retourné par votre application. Tout le long ce moment, votre application reprend 100 fois les mêmes opérations pour retourner un contenu identique.

La mis en cache est un procédé permettant d’améliorer considérablement le temps de chargement d’une page Web et économiser la bande passante, en évitant d’exécuter plusieurs fois certaines opérations (chargement des données, lecture d’une information dans la base de données, etc.) en stockant le contenu de cette page quelque part.

Activer la mise en cache

Le Framework ASP.NE MVC depuis la version 1 dispose d’un mécanisme pour la mise en a cache d’une application, qui repose essentiellement sur la même technique utilisée par ASP.NET. Il a été amélioré à partir de la version 3 pour coller avec les spécificités de la plateforme.

L’activation de la mise en cache se fait via l’attribut [OutputCache] qui peut être ajoutée soit individuellement à une action contrôleur, ou alors à une classe entière d’un contrôleur

Le code ci-dessous permet de mettre en cache pendant 30 secondes la sortie de l’action Index.

[OutputCache(Duration = 30)] //mise en cache pour 30 secondes
public ActionResult Index()
{
    ViewBag.Message = "Cette page a été mise e cache à " + DateTime.Now;

    return View();
}

Pour mettre en cache une classe entière d’un contrôleur, il suffit de décorer la classe avec l’attribut OutputCache comme l’illustre le code ci-dessous :

[OutputCache(Duration = 30)] //mise en cache pour 30 secondes
    public class HomeController : Controller
    {
       
        public ActionResult Index()
        {
            ViewBag.Message = "Cette page a été mise e cache à " + DateTime.Now;

            return View();
        }

        public ActionResult About()
        {
            ViewBag.Message = "Your app description page.";

            return View();
        }
}

Si vous exécutez ce code, vous vous rendrez compte que la date et l’heure affichées ne vont pas varier chaque fois que vous allez actualiser la page, jusqu’à ce que les 30 secondes soient écoulées.

NB: Il faut noter que le temps de sauvegarde des données de la page n’est pas garanti. En cas de manque de ressources mémoires, le cache va commencer à vider automatiquement son contenu.

Personnaliser la mise en cache

En dehors de la propriété Duration qui permet de définir le temps de mise en cache, d’autres propriétés dont il est important de connaitre sont disponibles pour vous permettre de personnaliser la mise en cache des données de votre page selon votre convenance et les spécificités de la page.

Location

La propriété location permet de définir l’emplacement pour enregistrer l’objet mis en cache. Il est possible d’enregistre l’objet mis en cache sur le serveur, le client, les deux ou toutes les autres options de l’enum OutputCacheLocation. Les différentes valeurs qu’elle peut prendre sont :

– Any
– Client
– Downstream
– Server
– None
– ServerAndClient

Par défaut, la valeur Any est utilisée lorsque cette propriété n’est pas spécifiée. L’orientation vers la mise en cache côté client, côté serveur ou les deux doit se faire suivant vos besoins. Si vous souhaitez afficher par exemple des informations personnalisées à l’utilisation comme son heure de connexion, son login, ses statistiques, etc. vous devez utiliser dans ce cas la mise en cache côté client.

Le code ci-dessous permet de mettre en cache la méthode d’action Index uniquement chez le client.

[OutputCache(Duration = 10, Location = OutputCacheLocation.Client)]
 public ActionResult Index()
 {
     ViewBag.Message = "Cette page a été mise en cache à " + DateTime.Now;

     return View();
 }

VaryByParam

Supposons un instant que vous voulez afficher les détails sur un produit à partir de son identifiant. Cela suppose qu’à chaque fois que l’identifiant du produit va changer, les détails affichés doivent également changer. Comment modifier la mise en cache pour que le contenu change automatiquement lorsque l’ID change. C’est à ce stade qu’intervient la propriété VaryByParam. Cette propriété permet de créer différentes versions d’un même contenu, dès que l’un des paramètres du formulaire ou de l’URL change.

Le code ci-dessous illustre comment vous pouvez l’utiliser.

[OutputCache(Duration = 3600, VaryByParam="id")]
        public ViewResult Details(short id)
        {
            Articles article = db.Articles.Find(id);
            return View(article);
        }

En procédant ainsi, plusieurs versions du contenu de la méthode d’action sont mises en cache jusqu’à expiration de la période de mise en cache.

Créer un profil de cache dans le Web.Config

Le fichier de configuration de votre application peut être utilisé pour créer un profil un cache. L’utilisation de cette technique présente plusieurs avantages :

– vous pouvez créer un profil de cache et appliquer celui-ci à plusieurs actions ou contrôleurs.

– vous pouvez modifier le comportement de votre profil de cache dans le Web.config sans avoir besoin de recompiler votre application.

Par exemple, la section de configuration Web « caching » définit un profil de cache nommé MyCacheProfil. Cette section « caching » doit apparaître dans la section « system.web » du fichier Web.Config.

<system.web>
    <caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add name="MyCacheProfile"  duration="60" />
        </outputCacheProfiles>
      </outputCacheSettings>
    </caching>
  </system.web>

Le contrôleur suivant illustre comment appliquer le profil MyCacheProfile sur une action contrôleur à l’aide de l’attribut [OutputCache].

[OutputCache(CacheProfile="MyCacheProfile")]
        public ActionResult Index()
        {
            ViewBag.Message = "Cette page a été mise en cache à " + DateTime.Now;

            return View();
        }

Le cache de sortie fournir un moyen simple pour améliorer radicalement les performances de vos applications ASP.Net MVC. Au travers de cet article, vous avez découvert comment vous pouvez utiliser cette technique. Restez connecté à mon blog pour la suite des astuces sur l’optimisation du temps de chargement d’une page Web.

Comme il n’est pas exclu que je tombe encore sur le même type de problème à l’avenir, je vais partager sur mon blog – qui est avant tout mon rappel mémoire favori – les causes de cette erreur et comment contourner cela.

Ce que j’essayais de faire dans mon application.

Pour une facture, je voulais récupérer la liste des produits, et pour chaque produit, avoir la fiche produit correspondante, y effectuer des modifications, ensuite appliquer la mise à jour à la base de données.

Le code source de cette partie est le suivant :

var lp = from l in db.Liste_produit.Include(l => l.Article)
         where l.Id_facture == facture.Id_facture
         select l;
foreach(Liste_produit liste_produit in lp)
     {
       article = liste_produit.Article;
       //bla bla bla
       //bla bla bla
       db.Entry(article).State = EntityState.Modified;
       db.SaveChanges();
                        
     }

À l’exécution de ce code, au moment de l’enregistrement des modifications dans la base de données (db.SaveChanges()), l’exception ci-dessous est levée.

Les causes :

Après avoir observé le problème de près et effectué quelques recherches, je me suis rendu compte que le souci était au niveau du foreach.

Il semblerait que pour la lecture de chaque élément dans « lp », la bouche ait recours à une transaction pour le Context en cours. Hor, lorsque j’appelle la procédure SaveChanges(), une nouvelle transaction veut être créée pour le même Context. Ce qui n’est pas autorisé par Entity Famework.

Solutions

De prime abord, j’ai opté pour la sauvegarde de mes données dans une IList. Ainsi, lors de la lecture de celles-ci, je n’aurais plus besoin d’avoir recours à une transaction.
Le code que j’ai utilisé est le suivant :

var lp = from l in db.Liste_produit.Include(l => l.Article)
         where l.Id_facture == fa.Id_facture
         select l;
IList<Liste_produit> ListeP = lp.ToList();
foreach(Liste_produit liste_produit in ListeP)
   {
      article = liste_produit.Article;
      //bla bla bla
      //bla bla bla
      db.Entry(article).State = EntityState.Modified;
      db.SaveChanges();
                        
  }

Cette solution marche. Mais, côté performance, elle n’est pas du tout satisfaisante. Si la quantité de données est importante, imaginez un peu la consommation de la mémoire en chargeant toutes ces données dans une liste.

En tout cas, elle ne m’arrange pas. J’ai donc opté pour une solution beaucoup plus simple et performante. J’ai simplement appelé la procédure SaveChanges() en dehors de la boucle et le problème a été résolu avec de meilleures performances.

var lp = from l in db.Liste_produit.Include(l => l.Article)
         where l.Id_facture == facture.Id_facture
         select l;
foreach(Liste_produit liste_produit in lp)
   {
      article = liste_produit.Article;
      //bla bla bla
      //bla bla bla
      db.Entry(article).State = EntityState.Modified;
   }
db.SaveChanges();

En procédant ainsi, j’apporte des modifications à l’entité dans le foreach, et c’est à la suite de cette instruction (lorsque la transaction a été bouclée) que j’appelle la procédure SaveChanges().

Voila le problème est résolu, et la prochaine fois que je serais face à ce problème (ce qui est fort probable), et que je ne me souviendrais plus de comment j’avais procédé (ce qui est également fort probable), je saurais ou chercher e premier ;).

En dehors d’un foutu message “Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information”, rien ne permet d’identifier clairement la source de cette erreur.

Après plusieurs recherches, il semblerait que l’erreur soit générée par Entity Framework. En effet, lorsque vous utilisez Entity Framework, celui-ci est configuré par défaut pour charger tous les types des assemblys référencées, afin d’identifier les différents types des entités pour votre modèle objet. Si l’un des types ne peut être chargé, alors Entity Framework va générer cette erreur.

Il existe plusieurs solutions pour fixer ce problème :

– vous pouvez marquer la copie locale de toutes les assemblys référencées dans votre application à True ;

– dans une autre mesure, il suffit de supprimer toutes les DLL dans le dossier bin et procéder à une nouvelle génération de votre application.

– il est également possible que les bibliothèques System.Data.Entity et System.Web.Entity soient corrompues. Pour mon cas par exemple, lors du déploiement de mon application, après investigation, je me suis rendu compte que les fichiers System.Data.Entity.dll et System.Web.Entity.dll avaient respectivement pour tailles 1640 Ko et 63 ko, pourtant dans le framework .NET, ces fichiers avaient pour tailles 4360 Ko et 135 Ko. En les remplaçant simplement avant le déploiement de l’application, cela a résolu ce bug.

Mais, le véritable problème ici, c’est d’identifier réellement l’assemblys qui pose problème. Pour cela, vous pouvez simplement utiliser le code suivant :

try
{
    //Le code qui pose problème.
}
catch (ReflectionTypeLoadException ex)
{
    StringBuilder sb = new StringBuilder();
    foreach (Exception exSub in ex.LoaderExceptions)
    {
        sb.AppendLine(exSub.Message);
        if (exSub is FileNotFoundException)
        {
            FileNotFoundException exFileNotFound = exSub as FileNotFoundException;
            if(!string.IsNullOrEmpty(exFileNotFound.FusionLog))
            {
                sb.AppendLine("Fusion Log:");
                sb.AppendLine(exFileNotFound.FusionLog);
            }
        }
        sb.AppendLine();
    }
    string errorMessage = sb.ToString();
   }

N’oubliez pas d’ajouter une référence à System.IO et System.Reflection;

Et voilà. Dorénavant, lorsque vous allez exécuter votre application et qu’il y’aura un problème avec le chargement d’un composant, vous aurez un message clair et les détails sur l’assembly qui pose problème.

À noter que ce bug n’existe plus lorsque l’on utilise Entity Framework avec le framework .NET 4.5, il ne scanne plus toutes les assemblys de l’application lors de son exécution.

Une des nouveautés les plus intéressantes qu’apporte Entity Framework 4.3 est la migration pour les mises à jour de la base de données.

Cette fonctionnalité offre aux développeurs des outils permettant d’appliquer avec souplesse et facilité des mises à jour à la base de données à partir des modifications apportées à l’application.

Dans un précédent billet de blog, j’ai présenté cette fonctionnalité et comment l’on pouvait l’utiliser pour effectuer des mises à jour de la base de données.

Cet article présentait uniquement l’un des modes de mises à jour qu’offre Entity Framework : le mode basé sur le code.

Supposons que vous disposez déjà d’une application utilisant Entity Framework Code First. Procédez à la mise à jour de celle-ci pour utiliser la version 4.3 d’Entity Framework si ce n’est pas encore le cas.

Vous pouvez utiliser la commande :

PM> install-package EntityFramework

Activer la migration

La première étape est d’activer la migration pour votre DbContext, en utilisant la console du gestionnaire de packages (menu Outils/Gestionnaire de package/Package Manager Console de Visual Studio). Vous allez exécuter la commande « Enabled-Migrations ».

L’activation de la migration crée un nouveau dossier Migrations dans votre application contenant un fichier Configurations.cs permettant de définir le comportement de la migration pour le DbContext qui est utilisé.

namespace DatabaseMigration.Migrations
{
    using System;
    using System.Data.Entity;
    using System.Data.Entity.Migrations;
    using System.Linq;

    internal sealed class Configuration : DbMigrationsConfiguration<DatabaseMigration.DatabaseMigrationContext>
    {
        public Configuration()
        {
            AutomaticMigrationsEnabled = false;
        }

        protected override void Seed(DatabaseMigration.DatabaseMigrationContext context)
        {
            
        }
    }
}

Si vous avez défini plusieurs «DbContext » dans votre application, il suffira juste de modifier DbMigrationsConfiguration(T), en remplaçant T par le nom du DbContext que vous voulez utiliser.

Configurer la migration automatique

Par défaut, la propriété AutomaticMigrationsEnabled est définie à false. Pour utiliser la migration automatique, vous devez affecter la valeur « true » à cette propriété.

Il également possible de définir cette propriété à true lors de l’activation de la migration. Pour cela, vous devez ajouter le paramètre EnableAutomaticMigrations à la commande permettant d’activer la migration :

PM> Enable-Migrations -EnableAutomaticMigrations

Par défaut, la migration automatique n’autorise pas les mises à jour pouvant entrainer des pertes de données. Pour activer cette option, vous devez éditer le fichier Configuration.cs en y ajoutant la propriété « AutomaticMigrationDataLossAllowed » qui sera définie à true.

public Configuration()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;
        }

Editez ensuite votre DbContext et ajoutez-y la procédure onModelCreating :

protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            Database.SetInitializer(new MigrateDatabaseToLatestVersion<DatabaseMigrationContext, Configuration>());
        }

Et voilà, c’est tout ;). Toute modification de votre modèle objet (nouvelle entité, ajout d’une propriété, suppression d’une propriété, etc.) sera automatiquement appliquée à la base de données à l’exécution de votre application.

Inconvénients de la migration automatique

La migration automatique permet d’apporter assez rapidement et simplement des mises à jour à une base de données en utilisant Entity Framework Code First. Cette option présente cependant des inconvénients, et personnellement, je ne recommanderais pas son utilise en environnement de production ou sur un système critique.

L’utilisation du mode automatique en environnement de production peut s’avérer assez dangereuse, avec un risque de perte de données, car les modifications apportées à la base de données sont imprévisibles par le développeur, et celui-ci n’a aucune visibilité sur ces changements.

Néanmoins, vous pouvez limiter ces risques en environnement de production en désactivant l’autorisation des mises à jour pouvant entrainer des pertes de données.

Cependant, jusqu’ici, lors de nos tests, vous pouvez vous rendre compte que notre application ne dispose d’aucun mécanisme permettant à un l’utilisateur à partir de l’interface de choisir une langue ou de basculer d’une langue à une autre à tout moment.

Cet aspect de l’internationalisation d’une application Web ASP.NET MVC 3 Razor fera l’objet de ce billet de blog.

Nous allons utiliser l’application que nous avons créée précédemment.

Dans notre cas, nous allons définir la langue qui est utilisée dans L’URL. Pour cela, nous allons commencer par définir la stratégie de routage qui sera utilisée dans notre application, en spécifiant la langue. L’URL que nous allons utilisera sous la forme suivante :

http://localhost/fr-fr/home/index pour le français
et
http://localhost/en-us/home/index pour l’anglais.

La route par défaut dans ASP.NET MVC 3 est définie sous la forme : http://localhost/controller/action/id. À partir de là, nous allons définir de nouveaux paramètres de route qui permettront de générer l’URL avec la langue. Pour cela, nous allons définir la route sous la forme suivante : http://localhost/lang/controller/action/id.

Pour atteindre ce résultat, il suffit de modifier le fichier Global.ascx.cs, et enregistrer une nouvelle route. Le code pour faire cela est le suivant :

public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
            routes.IgnoreRoute("favicon.ico");

            routes.MapRoute(
               "LocalizedDefault", // Route name
               "{lang}/{controller}/{action}/{id}", // URL with parameters
               new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
           );

            routes.MapRoute(
                "Default", // Route name
                "{controller}/{action}/{id}", // URL with parameters
                new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
            );
        }

Maintenant, vous devez ajouter un nouveau contrôleur (BaseController) qui héritera de System.Web.Mvc.Controller. Sa fonction principale sera de changer la langue du Thread d’exécution courant selon la valeur de la langue dans l’URL ou dans un cookie existant, et de sauvegarder le choix linguistique de l’utilisateur dans un cookie si ce n’est pas déjà fait. Si aucune langue n’est spécifiée dans l’URL, la langue du Thread d’exécution sera modifiée en utilisant par défaut la langue du navigateur de l’utilisateur.

Le code pour faire cela est le suivant :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Text;
using System.Threading;
using System.Globalization;

namespace MvcApplication1.Controllers
{
    public class BaseController : Controller
    {
        //
        // GET: /Base/

        protected override void ExecuteCore()
         {
             if (RouteData.Values["lang"] != null &&
              !string.IsNullOrWhiteSpace(RouteData.Values["lang"].ToString()))
             {
                 // modification de la culture dans les données de la route
                 var lang = RouteData.Values["lang"].ToString();
                 Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture(lang);
             }
             else
             {
                 // chargement de la culture depuis un cookie
                 var cookie = HttpContext.Request.Cookies["MvcApplication1.CurrentUICulture"];
                 var langHeader = string.Empty;
                 if (cookie != null)
                 {
                     // modification de la culture avec la valeur dans le cookie
                     langHeader = cookie.Value;
                     Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture(langHeader);
                 }
                 else
                 {
                     // utilisation de la langue par défaut du naviageteur si la culture n'est pas spécifiée
                     langHeader = HttpContext.Request.UserLanguages[0];
                     Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture(langHeader);
                 }
                 // modification de la culture dans les données de la route
                 RouteData.Values["lang"] = langHeader;
             }

             // sauvegarde de la culture dans un cookie
             HttpCookie _cookie = new HttpCookie("MvcApplication1.CurrentUICulture", Thread.CurrentThread.CurrentUICulture.Name);
             _cookie.Expires = DateTime.Now.AddYears(1);
             HttpContext.Response.SetCookie(_cookie);

             base.ExecuteCore();
         }

    }
}

Tous les contrôleurs de l’application doivent être modifiés pour hériter de ce contrôleur (Basecontrolleur).

public class HomeController : BaseController

Après avoir enregistré la route localisée, nous devons procéder à l’écriture d’une fonction permettant de générer l’URL localisée en fonction du choix de la langue de l’utilisateur.
Pour cela, nous allons ajouter un HTML Helper dans notre projet. Les Helpers HTML sont des méthodes d’extensions pour les classes HtmlHelper. Ces méthodes sont accessibles dans une vue à partir de la méthode HTML.

Le code pour notre Helper HTML est le suivant :

public static class SwitchLanguageHelper
    {
        public class Language
        {
            public string Url { get; set; }
            public string ActionName { get; set; }
            public string ControllerName { get; set; }
            public RouteValueDictionary RouteValues { get; set; }
            public bool IsSelected { get; set; }

            public MvcHtmlString HtmlSafeUrl
            {
                get
                {
                    return MvcHtmlString.Create(Url);
                }
            }
        }

        public static Language LanguageUrl(this HtmlHelper helper, string cultureName,
            string languageRouteName = "lang", bool strictSelected = false)
        {
            
            cultureName = cultureName.ToLower();
            // récuperation des valeurs de ka route depuis le view context
            var routeValues = new RouteValueDictionary(helper.ViewContext.RouteData.Values);
            
            //copie de la chaine de requête dans les valeurs de route pour générer le nouveau lien
            var queryString = helper.ViewContext.HttpContext.Request.QueryString;
            foreach (string key in queryString)
            {
                if (queryString[key] != null && !string.IsNullOrWhiteSpace(key))
                {
                    if (routeValues.ContainsKey(key))
                    {
                        routeValues[key] = queryString[key];
                    }
                    else
                    {
                        routeValues.Add(key, queryString[key]);
                    }
                }
            }
            var actionName = routeValues["action"].ToString();
            var controllerName = routeValues["controller"].ToString();
            //modification de la langue dans les valeurs de route
            routeValues[languageRouteName] = cultureName;
            //génération de l'url avec la langue
            var urlHelper = new UrlHelper(helper.ViewContext.RequestContext, helper.RouteCollection);
            var url = urlHelper.RouteUrl("LocalizedDefault", routeValues);
            // vérification si la culture courante correspond à celle passée en paramètre
            var current_lang_name = Thread.CurrentThread.CurrentUICulture.Name.ToLower();
            var isSelected = strictSelected ?
                current_lang_name == cultureName :
                current_lang_name.StartsWith(cultureName);
            return new Language()
            {
                Url = url,
                ActionName = actionName,
                ControllerName = controllerName,
                RouteValues = routeValues,
                IsSelected = isSelected
            };
        }

        
        public static MvcHtmlString LanguageSelectorLink(this HtmlHelper helper,
           string cultureName, string selectedText, string unselectedText,
           IDictionary htmlAttributes, string languageRouteName = "lang", bool strictSelected = false)
        {
            var language = helper.LanguageUrl(cultureName, languageRouteName, strictSelected);
            var link = helper.RouteLink(language.IsSelected ? selectedText : unselectedText,
                "LocalizedDefault", language.RouteValues);
            return link;
        }

       
    }

Enfin, dans le dossier View/Shared, nous allons ajouter une vue partielle (_SelectLanguage.cshtml) pour la sélection de la langue par l’utilisateur.
Le code pour cette page est le suivant :

@using MvcApplication1.MyHelper

@Html.LanguageSelectorLink("en-US", "[English]", "English", null)
@Html.LanguageSelectorLink("fr-FR", "[Français]", "Français", null)

La vue partielle doit être appelée dans le Layout de votre projet :

<div id="logindisplay">
                @Html.Partial("_LogOnPartial")
                @Html.Partial("_SelectLanguage
</div>

Nous pouvons maintenant exécuter l’application pour voir le résultat produit comme l’illustrent les captures suivantes :

Et voilà, nous venons de finir avec la dernière étape d’internationalisation de notre application. J’espère que ce tutoriel vous sera d’une grande utilité pour créer des applications ASP.NET MVC 3 multilingues ;).

En me basant donc du meilleur que j’ai pu tirer de quelques articles par-ci par-là et mon expérience, j’ai mis au point une solution qui répondait à mes besoins pour une application ASP.NET MVC Razor. Cette méthode n’est pas standard, et peut-être pas la meilleure, mais elle répond pleinement aux exigences de mon projet et aux objectifs que je voulais atteindre.

Ce qu’il faut savoir sur l’internationalisation dans l’écosystème .NET

Avant de se lancer dans la création d’un site multilingue en ASP.NET, il y a un certain nombre de concepts que vous devriez au préalable savoir. Lorsqu’on parle d’internationalisation d’une application sur la plateforme .NET, cela implique la mise en œuvre de deux mécanismes principaux à savoir : la mondialisation et la localisation.

La mondialisation est le processus de conception et de développement d’un produit logiciel adapté à plusieurs cultures. Une application mondialisée prend en charge des interfaces utilisateurs localisées et des données régionales pour tous les utilisateurs. Par exemple, le format de la date en zone francophone est jj/mm/aaaa. Dans les pays anglophones, nous avons plutôt le format mm/jj/aaaa. La mondialisation va consister à afficher le bon format dans une page en fonction de la langue du navigateur d’un utilisateur ou des options choisies par celui-ci.

La localisation est le processus d’adaptation de votre application à une culture et aux paramètres régionaux donnés. Vous devez pendant cette étape, personnaliser votre application pour les cultures auxquelles vous la destinez. Cette étape doit consister essentiellement en une traduction de l’interface utilisateur vers les langues cibles.

Différentes possibilités d’internationalisation d’une application ASP.NET

Il existe sur la plateforme .NET plusieurs procédés pour rendre son site multilingue. L’internationalisation d’une application peut donc être faite en utilisant soi :

– Les fichiers de ressources ;

– Des vues différentes pour chaque culture (traduction dans le code) ;

– Des fichiers texte ;

– Utiliser à la place des fichiers de ressources une base de données ;

– Ou combiner la première et la seconde méthode.

Chacune de ces techniques à ses avantages et ses inconvénients, et l’orientation vers l’une d’entre elles dépend aussi entre autres des spécifications de votre projet et des contraintes techniques auxquelles vous êtes confrontés. Personnellement je préfère les fichiers de ressources que j’utilise couramment lorsque je suis confronté à cette problématique.

Les fichiers ressources sont des fichiers textes optimisés. Au chargement, ils sont entièrement triés afin de limiter les accès que ce soit au niveau de la mémoire ou des différents disques.
C’est pourquoi, dans le cadre de ce tutoriel, nous nous limiterons uniquement à l’utilisation des fichiers de ressources.

Prérequis

– Visual Web Developer 2010 ;

– ASP.NET MVC 3 ;

– Connaissance de base en C# et sur le moteur de vue Razor.

Création de l’application

Nous allons commencer dès la base même, par la création d’une nouvelle application qui sera utilisée tout au long de l’article.
Pour ce faire, vous allez démarrer votre EDI Visual Studio. Cliquez sur le menu Fichier, ensuite sur la commande Nouveau projet. Dans la fenêtre qui va s’afficher, sélectionnez le Template de projet ASP.NET MVC 3 Web Application, renseignez le nom de l’application et l’emplacement ou celle-ci va être stockée et cliquez sur OK.

Sélectionnez ensuite dans la fenêtre qui va s’afficher le modèle de projet Internet Application, en vous assurant que le moteur de vue qui sera utilisé est Razor.

Cliquez ensuite sur OK pour que Visual Studio procède à la création de votre application.

Si vous exécutez l’application à ce stade, vous vous rendrez compte que le texte affiché par défaut dans vos pages est en anglais.

Puisque vous souhaitez que l’internaute qu’il soit anglophone ou francophone puissent se sentir à l’aise dans la navigation sur votre site, vous allez ajouter à celui-ci en plus du support de l’anglais, la prise en charge du français.

Pour atteindre ce résultat, les premières étapes suivantes sont nécessaires :

– Création des fichiers de ressources ;

– Modification des vues ;

– Définition de la culture.

Création des fichiers de ressources

Pour gérer efficacement l’internationalisation dans notre application, nous avons opté pour l’utilisation des fichiers de ressources pour stocker les valeurs qui doivent être localisées.

Ce qu’il faut savoir sur les fichiers de ressources

Une ressource est une donnée non exécutable qui est déployée logiquement avec une application. Les ressources peuvent contenir des données sous plusieurs formes, telles que des chaînes, des images ou des objets rendus persistants. Le stockage de vos données dans un fichier de ressources vous permet de changer les données sans avoir à recompiler l’intégralité de votre application.

Le format de fichier de ressources .resx se compose d’entrées XML, qui spécifient des objets et des chaînes dans des balises XML. Le .NET Framework fournit une prise en charge complète pour la création et la localisation des ressources. Ceux-ci doivent être créés d’une façon particulière pour fonctionner correctement.

Les fichiers de ressources de la langue par défaut de votre application doivent être nommés comme suit : nom_du_fichiers.resx.

Les fichiers pour les autres langues doivent suivre le format suivant : nom_du_fichier.culture.resx.

Ce qu’il faut savoir sur la culture

La culture ici doit définir le code la langue. Un code de langue est une convention symbolique permettant d’identifier une langue ou une variété dialectale ou régionale, ou un ensemble de langues par un identifiant défini dans un code, sans avoir à nommer la langue désignée elle-même.

La culture peut être neutre. Dans ce cas, elle sera codée sur deux caractères.

Exemple : en pour l’Anglais et fr pour le français.

Ou être stricte. Dans ce cas, elle sera codée sur quatre caractères ayant le format suivant « xx-XX », deux caractères minuscules pour la langue, et les deux suivantes en majuscules pour la variante régionale.

Exemple : fr-FR pour le français de France, en-US pour l’anglais des États-Unis et en-GB pour l’anglais de la Grande-Bretagne.

NB : Le fichier de ressource par défaut est utilisé si aucune culture n’est définie dans l’application ou si aucune ressource n’existe pour la culture qui a été définie.

Architecture.

Pour rester dans la logique de regroupement qu’impose ASP.NET MVC, il est préférable que l’arborescence de vos fichiers de ressources soit semblable à la capture ci-dessous :

Vous allez donc créer un dossier Ressources, en faisant un clic droit dans l’explorateur de projet et en cliquant sur Ajouter, puis en sélectionnant l’option Nouveau dossier.

Dans ce dossier vous allez procéder de même pour créer les dossiers Models, Views, etc.

Par la suite, vous devez créer les différents fichiers de ressources.
Je vous recommande de commencer par celui de la page Layout.chtml. Pour cela, vous allez créer les fichiers Layout.resx pour la langue par défaut et Layout.fr.resx pour le français.

Pour créer ces fichiers, faites un clic droit sur le sous-dossier Shared, sélectionnez l’option Ajouter, puis cliquez sur Ajouter un nouvel élément.
Dans la boite de dialogue qui va s’afficher, sélectionnez le type de fichier Ressources File, et renseignez le nom _Layout.resx dans la zone réserver à cet effet, puis cliquez sur Ajouter.

Faites de même pour créer le fichier Layout.fr.resx et les autres fichiers de ressources.

Maintenant, vous devez déplacer les textes qui sont dans votre fichier _Layout.cshtml dans le fichier de ressources, en renseignant le nom (comme celui d’une variable), la valeur (qui est le texte contenu dans le page) et une description s’il y a lieu.

Prenez la peine de vérifier que la zone « Acces Modifier » est définie à Public. Sinon, les valeurs que vous avez définies ne seront pas accessibles dans les vues.

Renseignez également la traduction de ces textes pour le fichier _Layout.fr.resx.

Attention, le nom doit être le même que celui que vous avez défini dans le fichier de ressources par défaut pour cette page.

NB : Contrairement à ASP.NET WebForms où il est conseillé de créer les fichiers de ressources dans les dossiers App_GlobalResources et App_LocalResources, avec ASP.NET MVC, l’utilisation de ces dossiers sera une source de problèmes pour vous. Je vous conseille donc d’utiliser un dossier différent (comme ce que nous avons fait plus haut), ou créer les ressources dans une librairie séparée.

Pour plus de détail sur le sujet, je vous invite à lire cet excellent billet de blog de K. Scott Allen : Resource Files and ASP.NET MVC Projects.

Modification de la vue

Maintenant que vous avez transféré le texte de la vue vers les fichiers de ressources, vous devez maintenant faire pointer les zones d’affichage de ces textes vers les ressources correspondantes.

Pour cela, ouvrez le fichier Layout.chstml et remplacez le texte suivant :

<div id="title">
   <h1>My MVC Application</h1>
</div>

Par

<div id="title">
   <h1> @MvcApplication1.Resources.Views.Shared._Layout.Title</h1>
</div>

En observant ces lignes de code, vous pouvez constater que la valeur est accessible comme une propriété de classe. En effet, toutes les ressources sont compilées vers une DLL (MvcApplication1.Resources.Views.Shared). Le nom du fichier (_Layout) est utilisé comme nom de la classe et le nom donné au texte est considéré comme celui de la propriété de la classe.

Premier aperçu

À ce stade, si tout est correct, vous pouvez déjà obtenir un premier aperçu de votre application localisée en définissant juste la culture qui est utilisée par celle-ci.

Pour cela, vous pouvez simplement définir la culture dans le fichier Globla.aspx en utilisant la méthode Application_BeginRequest qui est exécutée lors du lancement de l’application. Le code permettant de faire cela est le suivant :

protected void Application_BeginRequest(object sender, EventArgs e)
{
          
    Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture("fr");
} 

En modifiant le paramètre qui est passé à la fonction, CreateSpecificCulture() entre l’anglais(en) et le français(fr), on obtient le résultat suivant :

Nous avons défini une seule valeur localisée pour la vue Layout. Vous pouvez faire de même pour les autres vues.

Voilà, nous venons de finir avec les premières étapes d’internationalisation de notre application, qui nous ont permis de créer les fichiers de ressources et localiser nos vues. Dans la partie suivante, nous verrons comment procéder pour les fichiers du modèle avec les messages d’erreur de validation et comment mettre en ouvre un mécanisme de basculer entre les cultures sur l’interface utilisateur.

Lire la partie suivante : Internationalisation d’une application ASP.NET MVC 3 Razor part 2 : messages d’erreur de validation et DisplayAttribute

Cependant, avec ASP.NET MVC, il est possible de définir les messages des erreurs de validation dans le modèle, au sein des attributs fournis par l’espace de noms DataAnnotations utilisé pour la validation des données utilisateur. Il est également possible de définir les textes par défaut qui seront affichés dans les vues pour les intitulés des champs des formulaires.

Si vous avez donc défini ces infirmations dans votre modèle, vous allez vous rendre compte que ce que nous avons fait jusqu’ici ne permet pas de localiser ces champs texte.

Nous verrons donc dans ce billet comment internationaliser les messages des erreurs de validation et les intitulés des champs des formulaires définis dans le modèle.

Pour cet exemple, nous allons créer dans l’application que nous avons utilisée précédemment (dans la partie 1) un formulaire permettant l’enregistrement des produits. La classe qui sera utilisée est la suivante :

public class ProductModel
    {
        public string Name { get; set; }
        public string Description { get; set; }
        public decimal Price { get; set; }
    }

Pour créer le modèle correspondant, ajoutez au dossier Model un fichier de classe ProductModel.cs qui contiendra le code ci-dessus.

À ce stade, aucune logique de validation des données n’est implémentée. À l’aide de DataAnnotations nous allons mettre en œuvre la validation des données pour cette classe.

Le nouveau code de la classe ProductModel produit est le suivant :

public class ProductModel
    {
        [Required(ErrorMessage = "Le libellé du produit est obligatoire")]
        [Display(Name = "Nom")]
        public string Name { get; set; }
        [Required(ErrorMessage = "La description du produit est obligatoire")]
        [Display(Name = "Description")]
        public string Description { get; set; }
        [Required(ErrorMessage = "La prix est obligatoire")]
        [Display(Name = "Prix")]
        [Range(0.01, 400.00, ErrorMessage = "Le prix doit être compris entre 0.01 et 400.00")]
        public decimal Price { get; set; }
    }

Nous allons commencer par internationaliser les messages des erreurs de validation.

Pour cela, dans le sous-dossier Model du dossier Resources, vous allez créer deux nouveaux fichiers de ressources ProductModel, dans lesquels vous allez définir les messages d’erreurs de validation pour cette classe comme l’illustre la capture ci-dessous :

Pour localiser ces valeurs, nous allons utiliser les propriétés ErrorMessageResourceType et ErrorMessageResourceName.

La propriété ErrorMessageResourceType permet de spécifier le type de message d’erreur qui est associé à un contrôle de validation.
La propriété ErrorMessageResourceName, quant à elle, sera utilisée pour définir le nom de la ressource pour recherche le message d’erreur.

Le nouveau code de la classe ProductModel permettant donc de faire cela est le suivant :

public class ProductModel
    {
        [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "NameRequired")]
        [Display(Name = "Nom")]
        public string Name { get; set; }
         [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "DescriptionRequired")]
        [Display(Name = "Description")]
        public string Description { get; set; }
         [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "PriceRequired")]
        [Display(Name = "Prix")]
        [Range(0.01, 400.00, ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "PriceRange")]
        public decimal Price { get; set; }
    }

À ce stade, si nous exécutons notre application, nous obtenons le résultat suivant :

Pour l’anglais

Pour le français

Nous avons finalisé avec les messages des erreurs de validation. Passons maintenant à la localisation des attributs Display.

Avec la version précédente d’ASP.NET MVC, la définition des noms des propriétés qui seront affichées dans l’interface utilisateur se faisait en décorant la propriété avec la classe DisplayNameAttribute. Cependant, elle ne possède qu’un seul constructeur et ne supporte pas de ce fait la localisation.

Pour internationaliser donc ces valeurs, il fallait du code personnalisé après beaucoup d’effort de programmation. Ce problème est résolu avec ASP.NET MVC 3. La localisation des noms des propriétés peut se faire assez aisément dans le modèle en utilisant la classe DisplayAttribute.

Cette classe possède plusieurs propriétés, y compris les propriétés ResourceType, permettant de définir le type de ressource pour les propriétés localisées et Name pour définir le nom de la ressource.

Le nouveau code de la classe ProductModel sera donc le suivant :

public class ProductModel
    {
        [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "NameRequired")]
        [Display(Name = "DisplayName", ResourceType = typeof(MvcApplication1.Resources.Models.ProductModel))]
         public string Name { get; set; }
         [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "DescriptionRequired")]
         [Display(Name = "DisplayDescription", ResourceType = typeof(MvcApplication1.Resources.Models.ProductModel))]
        public string Description { get; set; }
         [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "PriceRequired")]
         [Display(Name = "DisplayPrice", ResourceType = typeof(MvcApplication1.Resources.Models.ProductModel))]
        [Range(0.01, 400.00, ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "PriceRange")]
        public decimal Price { get; set; }
    }

Les fichiers de ressources utilisés seront modifiés comme suit :

À ce stade, si nous exécutons notre application, nous obtenons le résultat suivant :

Pour l’anglais

Pour le français

Et voilà, nous venons de finir avec la localisation des textes du modèle. Vous pouvez vous rendre compte combien il est facile grâce aux nouveautés introduites par ASP.NET MVC 3 d’internationaliser les messages d’erreur de validation et les intitulés des champs des formulaires dans la vue.

La prochaine étape sera la mise au point sur l’interface utilisateur d’un mécanisme permettant à l’internaute de modifier la culture pour faire passer l’application d’une langue à une autre.

Au vu de mon orientation de plus en plus vers ASP.NET MVC pour la conception de mes applications, je me suis dit qu’il était temps pour moi malgré tous les articles que j’ai lus en ligne sur les nouvelles fonctionnalités de la version 3 du Framework, de me mettre à la lecture d’un livre qui traite du sujet.

Mon choix s’est porté sur Professional ASP.NET MVC 3, qui est écrit par Phil Haack et Brad Wilson, qui font partie de l’équipe de développement du framework, ainsi que Jon Galloway et K. Scott Allen, des pionniers de la technologie. Ce livre est le guide parfait pour toute personne désireuse de maitriser le framework ASP.NET MVC 3.

Contrairement au titre qui donne l’impression d’un livre réservé aux professionnels, le chapitre 1 un présente de façon détaillée le framework (description, installation, création d’une première application, etc.) et effectue une comparaison avec ASP.NET et les raisons qui ont entrainé sa création. Le chapitre 2, également un chapitre introductif pour moi, revient en détail sur la notion de contrôleur. C’est à compter des chapitres trois et quatre présentant respectivement la vue et le modèle, que le lecteur découvrira les nouveautés intéressantes comme le moteur de vue Razor, l’échafaudage et Entity Framework Code First. L’utilisation des formulaires, des helpers HTML et les améliorations apportées à la validation des données utilisateur notamment avec DataAnnotations seront décrites dans les deux chapitres suivants.

>>Lire la suite!

Plusieurs techniques peuvent être utilisées pour optimiser les performances d’une application Web (mise en cache, compression des fichiers, minification, etc). Je vais me pencher aujourd’hui sur le package NuGet d’optimisation d’un site Web « ASP.NET Optimization – Bundling » qui a été publié récemment par Microsoft.

Ce package ajoute le support du regroupement et de la minification des fichiers JavaScript et CSS – qui sont des caractéristiques d’ASP.NET 4.5 et ASP.NET MVC 4 (disponibles actuellement en version Developper Preview) – avec le minimum d’effort pour les applications ASP.NET 4 et ASP.NET MVC.

Le regroupement et la minification sont des procédés de réduction de la taille des fichiers en les combinant, et en supprimant les espaces et autres caractères inutiles. Ces méthodes permettent de rendre l’exécution d’une page Web plus rapide avec le moins de demandes de chargement des fichiers.

Nous verrons dans ce billet de blog comment améliorer les performances d’une application Web ASP.NET MVC en utilisant les techniques de regroupement et de minification introduites par le package Microsoft.Web.Optimisation.

Pour commencer, nous allons créer un nouveau projet ASP.NET MVC 3.
Comme l’illustre l’image ci-dessous, nous constatons que notre application contient par défaut un nombre déjà assez important de fichiers JavaScript et CSS.

En exécutant une page de cette application (LogOn.chtml), nous obtenons les statistiques suivantes issues de l’analyse d’un outil de mesure de performance comme YSlow.

Pour cette page, nous avons un nombre total de 7 requêtes HTTP qui ont été effectuées, avec 4 fichiers JavaScript d’une taille totale de 119,9K qui ont été chargés.

Nous allons maintenant essayer de réduire le nombre de requêtes et la taille des fichiers qui sont chargés en utilisant ASP.NeT Optimisation Bundle.

Pour cela, nous allons dans un premier temps ajouter une référence à Microsoft.Web.Optimisation dans notre application.

L’ajout de ce composant se fera via NuGet. Pour installer le package en utilisant NuGet voir mon article sur NuGet.

Après avoir installé le package, nous pouvons démarrer le regroupement et la minificatioon de nos fichiers en ajoutant tout simplement la ligne de code suivant dans la procédure Application_Start() du fichier Global.asax.cs.

BundleTable.Bundles.EnableDefaultBundles();

Et c’est tout ;).

N’oubliez pas d’ajouter une référence à Microsoft.Web.Optimization dans le fichier Global.asax.cs :

using Microsoft.Web.Optimization;

Tous les fichiers JavaScript contenus dans le répertoire Scripts (les sous dossiers ne sont pas pris en compte) de notre application seront regroupés, compressés et traités comme un seul fichier. Ces fichiers seront regroupés par défaut dans un dossier Script.

Ils seront désormais référencés en utilisant la ligne de code suivante :

<script src="@Url.Content("/Scripts/js")" type="text/javascript"></script>

De même, les fichiers CSS contenus dans le répertoire Content seront également compactés par défaut dans un dossier Content.

Ils seront référencés en utilisant la ligne de code suivante :

<link href="@Url.Content("/Content/css")" rel="stylesheet" type="text/css" />

Après avoir appliqué ces modifications, exécutons à nouveau la page précédente. Nous obtenons le résultat suivant :

En comparant avec le résultat précédent, nous constatons que le nombre de requêtes est passé de 7 à 4, avec l’utilisation d’un fichier JavaScript unique, contre quatre précédemment.
C’est déjà une bonne chose. Par contre, on se rend compte que la taille du JavaScript a plutôt augmenté, passant de 119,9k à 437,5k.

Pourquoi avons-nous plutôt une augmentation de la taille du JavaScript ?

En utilisant le dossier Scripts par défaut, ce sont environ une vingtaine de fichiers JavaScript contenus dans notre application ASP.NET MVC qui sont regroupés, minifiés et référencés dans une page qui n’utilise que quatre de ces fichiers.
C’est tout à fait normal donc que malgré l’opération d’optimisation, on se retrouve avec une taille totale de ces fichiers supérieure à celle des quatre référencés dans notre page.

Pour pallier à cela, nous pouvons définir nos propres regroupements de fichiers.

Avec cette option, nous avons la liberté dans le choix des fichiers qui seront dans un regroupement, ainsi que l’URL qu’aura le regroupement. À ce stade, le choix des dossiers de regroupement doit être fonction de la récurrence des fichiers JavaScript et CSS dans les pages de votre application.

Nous pouvons définir nos regroupements personnalisés en procédant comme suit dans la procédure Application_Start() du fichier Global.asax.cs :

BundleTable.Bundles.EnableDefaultBundles();

Bundle jsBundle = new Bundle("~/Scripts",typeof(JsMinify));
jsBundle.AddFile("~/Scripts/jquery-1.5.1.min.js");
jsBundle.AddFile("~/Scripts/modernizr-1.7.min.js");
jsBundle.AddFile("~/Scripts/jquery.validate.min.js");
jsBundle.AddFile("~/Scripts/jquery.validate.unobtrusive.min.js");

BundleTable.Bundles.Add(jsBundle);

Bundle cssBundle = new Bundle("~/Style", typeof(CssMinify));
cssBundle.AddFile("~/content/themes/site.css");
cssBundle.AddFile("~/content/themes/base/jquery.ui.all.css");

BundleTable.Bundles.Add(cssBundle);

Nous allons désormais référencer ces regroupements dans notre page comme suit :

<link href="@Url.Content("~/Style ")" rel="stylesheet" type="text/css" />
<script src="@Url.Content("~/Scripts")" type="text/javascript"></script>

Et en exécutant la page précédente, nous obtenons le résultat suivant :

Et voilà, la taille de nos fichiers JavaScript passe de 119,9K à 2,3K, soit une réduction de plus de 95 %.

Vous pouvez également ajouter à votre regroupement tous les fichiers JavaScript d’un répertoire en procédant comme suit :

jsBundle.AddDirectory("~/Scripts", "*.js", false);

Nous avons maintenant de quoi compresser et réduire au maximum le nombre de hits de nos pages Web avec souplesse.

Seul bémol, la minification des fichiers contenant du code CSS3 semble ne pas fonctionner pour l’instant.

À première vue, il semblerait qu’il y ait une référence circulaire dans ma hiérarchie d’objets qui n’est pas prise en charge par le sérialiseur JSON.

En essayant de procéder au débogage de la procédure, je me suis rendu compte que le problème n’était pas au niveau de mon code, mais plutôt au niveau de la classe qui s’occupe de la sérialisation.

Quelle est donc la cause de cette erreur :

Pour les tables ayant des relations, l’utilitaire de mappage objet relationnel, génère des propriétés de référence dans chaque entité.

Prenons par exemple le schéma suivant de ma base de données :

Pour la table Liste_produit, L’objet généré aura une propriété Facture. Cependant, pour la table Facture, l’objet généré aura également une propriété Liste_produit. Conséquence : l’objet facture est lié à l’objet Liste_produit et vice-versa.

Ce scénario permet bien évidemment de bénéficier de beaucoup plus d’options lors du traitement de ces entités, mais crée cependant une ambiguïté pour le sérialiseur JSON lors de l’opération de sérialisation. D’où la génération de cette erreur.

Comment résoudre cela ?

Pour résoudre ce type de problème, nous pouvons utiliser deux solutions.

La première solution qui est plutôt simple est de marquer la relation comme une propriété interne.

Perso, je préfère ne pas utiliser cette méthode, car elle m’oblige à modifier mon EDM (Entity Data Model).

La seconde solution, qui est celle pour laquelle j’ai opté, consiste en l’utilisation d’un autre ViewModel en lieu et place de celui généré automatiquement par l’utilitaire de mappage objet/relationnel (ORM).

Cette approche est plus élégante dans la mesure ou elle permettra de sélectionner uniquement les données dont nous avons besoin et sérialiser uniquement celles qui nous intéressent. La conséquence directe est la réduction de la taille des données qui seront retournées dans notre vue et une amélioration de performance de notre application.

Pour utiliser cette méthode, nous devons :

– Dans un premier temps, créer une nouvelle classe qui contiendra uniquement les propriétés dont nous avons besoin.

public partial class ProduitL
    {

        public short Id_produit 
        {
            get; 
            set; 
        }
        public string Libelle_produit 
        { 
            get; 
            set; 
        }
        public string Conditionnement 
        { 
            get; 
            set; 
        }
        public int Quantite 
        { 
            get; 
            set; 
        }
        public decimal Prix 
        { 
            get; 
            set; 
        }
    }

Nous allons ensuite modifier la méthode d’action de notre contrôleur comme suit :

public JsonResult Facture(short id)
        {

            var results = from lp in db.Liste_produit
                    where lp.Id_facture == id
                    select new ProduitL
                    {
                        Id_produit = lp.Id_produit,
                        Libelle_produit = lp.produit.Libelle_ produit,
                        Conditionnement = lp. produit.Conditionnement,
                        Quantite = lp.Quantite,
                        Prix = lp.Prix  
                        
                    };
            return Json(results);
        }

ET voilà, à l’exécution de notre application, nous n’aurons plus cette erreur qui peut s’avérer désorientant pour certains.