Le Web évolue rapidement, et Microsoft est conscient de cela. L’éditeur a ainsi adopté un cycle de mise à jour pour ASP.NET plus rapide que celui de Visual Studio.

La société compte donc publier une mise à jour pour sa plateforme de développement Web ASP.NET en début d’année prochaine.

Les développeurs qui veulent commencer à « jouer » avec les nouvelles fonctionnalités de cette mise à jour peuvent déjà télécharger sa version Release Candidate (RC) qui vient d’être publiée par les équipes ASP.NET et Visual Web Developer de Microsoft.

« ASP.NET et Web Tools 2012.2 » RC étend le runtine ASP.NET existant et ajout de nouveaux outils Web à Visual Studio 2012 pour WebForms, MVC, WebAPI, etc. Il s’agit des fonctionnalités suivantes :

1. De nouveaux modèles de projets ASP.NET MVC. la création d’applications Facebook est désormais plus facile avec le modèle Facebook, qui permet en quelques étapes de créer une application qui interagir avec le réseau social. Le nouveau modèle « Single Page Application » permet aux développeurs de créer des applications Web interactives côté client à l’aide de jQuery, Knockout et ASP.NET Web API ;
2. Le support de la communication en temps réel avec ASP.NET SignalR. SignalR est une bibliothèque client/serveur qui permet aux clients basés sur un navigateur et aux composants serveur basés sur ASP.NET d’avoir une conversation à étapes multiples et bidirectionnelle;
3. Le support de l’IntelliSense pour Knockout et l’ajout de la prise en charge de JSON en tant que classe ;
4. L’introduction de nouvelles fonctionnalités pour ASP.NET Web API, y compris le support d’OData, l’ajout des fonctions de traçabilité, de monitoring et de génération d’une page d’aide pour une API Web;
5. Des améliorations de l’inspecteur de page, qui offre désormais de meilleures performances pour JavaScript et CSS, dont la capacité de voir les mises à jour en temps réel d’un fichier CSS ;
6. L’unification de l’expérience de publication pour une application Web et un projet de type site Web, ainsi que l’ajout des options de publication sélective ;
7. L’intégration de la nouvelle fonctionnalité ASP.NET Friendly URL. Cette fonction rend facile la génération des URL sans l’extension .aspx. Elle permet également au développeur d’ajouter plus facilement le support du mobile dans son application Web ;
8. La mise à jour des modèles de projets Web dans Visual Studio 2012.

Cette mise à jour est livrée comme des packages NuGet supplémentaires. Ce qui signifie qu’il ne peut avoir aucun problème de compatibilité avec les projets existants.

Télécharger « ASP.NET et Web Tools 2012.2″ RC

Dans ce article, nous avons créer une première API et consommer celle-ci dans une page Web en utilisant jQuery. Dans ce billet de blog, je vais vous montrer comment vous pouvez interagir avec votre API dans une application native en utilisant HttpClient.

Dans une application Web, vous pouvez simplement interagir avec une API Web coté client en appelant les requêtes HTTP Get, Put, Post et Delete dans un Script JavaScript ou en utilisant jQuery. Mais, si vous voulez accéder à votre API à partir d’une application Desktop par exemple, comment procéder ?

C’est à ce niveau qu’intervient HTTPClient. HTTPClient est un client moderne HTTP pour les applications .NET. Il peut être utilisé pour consommer avec souplesse et simplicité les fonctionnalités exposées via HTTP. Vous pouvez utiliser HTTPClient pour mettre en œuvre des interactions avec une API Web en envoyant et en recevant des réponses à partir des verbes standards Get, Put, Post et Delete de HTTP grâce aux méthodes GetAsync, PutAsync, PostAsync, DeleteAsync.

L’exemple ci-dessous illustre comment vous pouvez consommer les données au format XML d’une API Web en utilisant la méthode GetAsync.

HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/xml"));
var response = client.GetAsync("http://localhost:59130/api/Customer").Result;

Si vous souhaitez que les données soient retournées au format XML, vous pouvez procéder comme suit :

HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
var response = client.GetAsync("http://localhost:59130/api/Customer").Result;

La procédure client.DefaultRequestHeaders.Accept.Add() permet de définir le format qui sera utilisé pour sérialiser les données.

La procédure asynchrone GetAsync() de la classe HttpClient() prend en paramètre une URI ou une chaine de caractères qui représente l’URL de l’API Web. GetAsync effectue une requête HTTP GET en utilisant l’URL passée en paramètre, puis retourne directement une tache dont la propriété Result (Task.Result) contient la réponse HTTP (HttpResponseMessage).

NB : Il est recommandé lors de l’utilisation d’une méthode asynchrone d’utiliser également le mot clé await pour éviter que l’application ne soit bloquée jusqu’à ce que l’opération soit complète. On peut s’en passer pour une application console, mais pour une solution Desktop, faudra penser à utiliser await pour éviter le blocage de l’interface utilisateur. Pour plus de détails sur async et await, je vous invite à lire cet excellent article sur le sujet : les nouveautés de C# 5.0.

A titre d’exemple, vous allez créer une application console qui consomme l’API que vous avez créée ci-dessus. Cliquez sur le menu « FICHIER », sélectionnez « Ajouter » puis « Nouveau projet ». Sélectionnez le projet « Application Console » et donnez-lui le nom « TestFirstWebAPI ».

Après création du projet, vous allez ajouter une référence à HTTPClient. HTTPClient n’étant pas disponible par défaut dans le Framework .NET ou avec ASP.NET MVC 4, vous devez passer par le gestionnaire de packages NuGet pour ajouter cette dépendance à votre application.

Faites un clic droit sur votre projet dans l’explorateur de solution et sélectionnez la commande « Gérer les packages NuGet… ». Lorsque l’interface de NuGet va s’afficher, recherchez le package HTTPClient.

L’installation du package va entrainer l’installation des dépendances System.Net.Http et System.Json que vous allez utiliser dans votre application.

Ajoutez une classe dans votre projet ayant la même définition que la classe Customer dans le projet ASP.NET MVC. Pour rappel, cette classe doit avoir la définition suivante :

public class Customer
    {
        public int Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string EMail { get; set; }
    }

Ajoutez par la suite une référence à System.Net.Http.Formatting et System.Net.Http.Headers.

using System.Net.Http.Formatting;
using System.Net.Http.Headers;

Vous allez maintenant ajouter les lignes de code suivantes à la fonction Main de votre application.

HttpClient client = new HttpClient();


client.DefaultRequestHeaders.Accept.Add(
     new MediaTypeWithQualityHeaderValue("application/json"));

 var response = client.GetAsync("http://localhost:59130/api/customer").Result;  

 if (response.IsSuccessStatusCode)
 {
     
     var Customers = response.Content.ReadAsAsync<IEnumerable<Customer>>().Result;
     foreach (var c in Customers)
     {
         Console.WriteLine("{0}\t{1}\t{2}", c.FirstName, c.LastName, c.EMail);
        
     }
 }
 else
 {
     Console.WriteLine("{0} ({1})", (int)response.StatusCode, response.ReasonPhrase);
 }
     Console.ReadLine();

La procédure ReadAsAsync() lit et déserialise automatiquement le corps de la réponse HTTP qui contient la liste des clients.

En appuyant sur F5 pour lancer le débogage de votre application, vous allez obtenir le résultat suivant :

Rassurez vous que vous utilisez un numéro de port spécifique pour votre application (59130 pour mon cas). Vous pouvez vérifier cela dans les propriétés du projet, onglet Web :

Vous avez le choix entre utiliser un numéro de port spécifique ou utiliser le serveur Web IIS local si vous en avez. Dans ces cas, le numéro de port ne varie que si vous décidez de le modifier.

Un petit message pour annoncer la publication de mon nouvel article sur le regroupement et la minification du JavaScript et CSS, des techniques d’optimisation qu’apporte ASP.NET MVC 4, pouvant grandement influencer le temps de chargement des pages Web.

Le temps de chargement d’une page est un facteur important dans l’évaluation des performances d’un site Web. Il a un impact non négligeable sur l’expérience utilisateur et même sur le référencement naturel. Plus les pages de votre site se chargent rapidement, plus l’expérience de navigation est fluide et plus les utilisateurs sont contents.

Dans nos applications, nous avons recours à plusieurs bibliothèques dont jQuery, knockout, etc. et des feuilles de styles qui ont des conséquences non négligeables sur le temps de chargement des pages.

Dans cet article, nous verrons comment améliorer les performances d’une application Web ASP.NET MVC en utilisant le regroupement et la minification à la volée du CSS et JavaScript.

L’article complet peut-être consulté sur cette page.

Pour les commentaires, ça se passe ici.

Télécharger le ZIP de l’article.

Télécharger l’article au format PDF.

Télécharger l’article au format eBooks.

Bonne lecture

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.

Pendant le développement ou le cycle de vie d’une application, le développeur est très souvent confronté à des situations pouvant entrainer des modifications de son modèle objet ainsi que de sa base de données. Avec Entity Framework, cette tâche peut s’avérer assez complexe, voire frustrante pour certains.

Si vous voulez par exemple apporter une modification (ajout d’une colonne) à une table de votre base de données, si vous vous limitez à définir uniquement la nouvelle colonne dans votre modèle, lors de l’exécution de l’application vous allez obtenir un message d’erreur puisque le modèle ne correspond plus aux objets de la BD.

Il était cependant possible d’ajouter quelques lignes de code dans le fichier Global.asax, permettant lors de la modification du modèle, de détruire et recréer automatiquement la base de données lors de la prochaine exécution de l’application, avec comme conséquence directe la perte des données. Ce qui est inacceptable pour une base de données déjà en production.

Heureusement, Entity Framework 4.3 élimine ces contraintes avec la nouvelle fonctionnalité Code First Migrations, qui permet d’appliquer avec souplesse les modifications du modèle sur la base de données, en réduisant les risques de pertes de données.

L’article complet est disponible ici.

Pour les commentaires, ça se passe ici

Bonne lecture

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.

Dans mon précédent billet de blog sur WebAPI, j’ai décrit comment utiliser WebAPi dans une application ASP.NET MVC. Mais, il est également possible de l’utiliser dans une application ASP.NET WebForms.

Je vais montrer dans cet article comment utiliser simplement WebAPI dans une application ASP.NET. Dès lors que vous avez installé ASP.NET MVC 4 beta, vous pouvez dans n’importe quel projet (Application Web, Site Web) ajouter un contrôleur WebAPI. Celui-ci va automatiquement intégrer dans votre solution toutes les références nécessaires pour WebAPI.

Pour illustrer cela, vous allez créer une nouvelle application Web ASP.NET. Vous devez au préalable avoir installé ASP.NET MVC 4 beta.

Dans l’application, vous allez ajouter un dossier App_Code. Ensuite, vous allez créer la classe Web API Controller dans ce dossier en faisant un clic droit sur celui-ci, puis en sélectionnant Add, et ensuite New Item :

Dans la fenêtre de sélection du Template, vous verrez un nouveau Template « Web API Controller Class ». Sélectionnez celui-ci, et renommez le fichier en vous assurant que le nom s’achève par « Controller ». Puis cliquez sur « Add » :

Un nouveau contrôleur Web API qui hérite de ApiController sera créé dans le dossier App_code avec des lignes de code par défaut illustrant comment vous pouvez créer des requêtes Get(), Post(), Put() et Delete() pour votre API.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net.Http;
using System.Web.Http;

namespace WebApplication1.App_Code.Controllers
{
    public class ValuesController : ApiController
    {
        // GET /api/<controller>
        public IEnumerable<string> Get()
        {
            return new string[] { "value1", "value2" };
        }

        // GET /api/<controller>/5
        public string Get(int id)
        {
            return "value";
        }

        // POST /api/<controller>
        public void Post(string value)
        {
        }

        // PUT /api/<controller>/5
        public void Put(int id, string value)
        {
        }

        // DELETE /api/<controller>/5
        public void Delete(int id)
        {
        }
    }
}

Pour ce billet, on se limitera uniquement à l’utilisation du code généré.

Exposer les fonctionnalités de l’API

Vous allez maintenant définir une route pour WebAPI afin de pouvoir exposer les fonctionnalités de votre API.

Pour cela, vous allez ajouter les lignes de suivantes dans la méthode Application-Start du fichier Global.ascx.cs.

void Application_Start(object sender, EventArgs e)
        {
            // Code that runs on application startup
            RouteTable.Routes.MapHttpRoute(
            name: "DefaultApi",
              routeTemplate: "api/{controller}/{id}",
              defaults: new { id = System.Web.Http.RouteParameter.Optional }
          );

        }

Vous devez également ajouter une référence à System.Web.Routing et System.Web.Http

Consommer l’API

Voyons maintenant comment vous pouvez consommer L’API créée. Il est possible d’appeler votre service en utilisant JavaScript, Ajax ou HttpClient.

Le script ci-dessous permet d’appeler le verbe Get pour lire les données en utilisant JavaScript.

<script type="text/javascript">
    $(document).ready(function () {
        // Envoi de la requête Ajax
          $.getJSON("api/values/",
             function (data) {
                // En cas de succès, 'data' contient la liste des clients.
                   $.each(data, function (key, val) {
                    var str = val;
                    $('<li/>', { html: str }).appendTo($('#getvalues'));
                });
            });
    });
</script>

Les lignes ci-dessous seront utilisées pour afficher les informations retournées.

<h1>GET VALUES</h1>
<ul id='getvalues' />

A l’exécution, vous allez obtenir le résultat suivant :

Nb : Si vous ne disposez pas d’ASP.NET MVC 4 beta, vous pouvez télécharger et installer séparément le package ASP.NET Web API via le gestionnaire de packages NuGet.

Précédemment, avec Code First, si vous vouliez apporter une modification (ajout d’une colonne par exemple) à une table de votre base de données, si vous vous limitiez à définir uniquement la nouvelle colonne dans votre modèle, lors de l’exécution de l’application vous obteniez un message d’erreur puisque le modèle ne correspond plus aux objets de la BD.

En apportant les modifications du côté de la base de données, il fallait de nouveau mettre à jour le modèle. Cette action avait pour conséquence de régénérer à nouveau le modèle, avec éventuellement la perte de la personnalisation (message d’erreur de validation, définition des attributs Display, etc.) que vous aviez effectué dans votre modèle.

Avec la migration de base de données introduite par la version 4.3.1 d’Entity Framework, des modifications peuvent être apportées facilement et aisément à la base de données à partir du modèle.

Assez de charabia. Voyons concrètement de quoi il s’agit en touchant cette nouveauté « du bout du doigt ».

Créez une nouvelle application ASP.NET MVC 4 « DataMigration » en utilisant le modèle Internet Application. Avec NuGet, vous allez faire une mise à jour d’Entity Framework vers la dernière version de la bibliothèque qui ajoute les fonctionnalités de migration des bases de données.

Vous devez maintenant ajouter une nouvelle classe « Customer » dans le modèle représentant un client. Le code de cette classe est le suivant :

public class Customer
    {
        public short Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
       
    }

Vous allez par la suite créer un nouveau contrôleur en utilisant Entity Framework pour les actions CRUD.

Dans les options de scalffolding, vous devez sélectionner la classe Customer. Dans la zone Data context class, vous allez sélectionner « New data context…>. Renseignez le nom du Data Context « DataMigrationContext », validez ensuite sur OK et cliquez enfin sur Ajouter.

Un fichier DataMigrationContext.cs sera automatiquement ajouté à l’application.

Exécutez l’application pour que Code First utilise le modèle pour créer la base de données qui sera automatiquement ajoutée à votre instance SQLEXPRESS locale.

Activation de la migration

Supposons que vous avez oublié une propriété Email dans votre modèle. Vous allez donc modifier celui-ci en ajoutant cette nouvelle propriété :

public class Customer
    {
        public short Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string EMail { get; set; }

    }

Si vous exécutez votre application ainsi, vous allez obtenir le message d’erreur suivant :

Comme l’exception le signale, il est temps pour vous d’utiliser Code First Migrations pour procéder à la mise à jour de votre base de données.

La première étape est d’activer la migration pour votre Context, en utilisant la console du gestionnaire de packages. Vous allez exécuter la commande suivante : 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 Context, et un autre fichier contenant une procédure Up() qui contient des instructions pour créer la table avec la définition initiale de celle-ci, et une autre procédure Down pour supprimer la table.

public partial class InitialCreate : DbMigration
    {
        public override void Up()
        {
            CreateTable(
                "Customers",
                c => new
                    {
                        Id = c.Short(nullable: false, identity: true),
                        FirstName = c.String(),
                        LastName = c.String(),
                    })
                .PrimaryKey(t => t.Id);
            
        }
        
        public override void Down()
        {
            DropTable("Customers");
        }
    }

Ajout d’une nouvelle migration

Vous allez maintenant ajouter une nouvelle migration pour prendre en compte le nouvel attribut dans la base de données. Vous allez utiliser la commande Add-Migration suivie du nom de la migration :

Un nouveau fichier 201203082156197_FirstMigration.cs sera automatiquement ajouté au dossier Migrations :

Ce fichier contient par défaut le code suivant :

namespace DataMigration.Migrations
{
    using System.Data.Entity.Migrations;
    
    public partial class FirstMigration : DbMigration
    {
        public override void Up()
        {
            AddColumn("Customers", "EMail", c => c.String());
        }
        
        public override void Down()
        {
            DropColumn("Customers", "EMail");
        }
    }
}

Vous pouvez apporter des modifications à ce fichier en ajoutant ou supprimant de nouvelles colonnes. Lorsque tout est Ok, vous pouvez utiliser la commande Update-Database pour appliquer cette migration sur la base de données.

Vous pouvez observer les modifications qui ont été apportées à la base de données dans l’explorateur de serveur:

Et voilà, vous venez grâce à Code First Migrations d’apporter les modifications qui ont été effectuées du côté du code de votre application à la base de données.

Aujourd’hui, je vais revenir sur l’une de ces nouveautés les plus importantes à savoir : Web API. ASP.NET Web API a pour objectif principal de permettre aux développeurs d’exposer leurs applications, données et services sur le web directement à travers HTTP.

Le support d’ASP.NET Web API permet de créer facilement des API Web puissantes, qui peuvent être consultées à partir d’un large éventail de client (réseaux sociaux, navigateurs, terminaux mobiles, etc.). Web API fournit les fonctionnalités suivantes :

• Modèle de programmation HTTP moderne : l’API Web permet d’accéder directement et manipuler les requêtes et réponses HTTP à l’aide d’un nouveau modèle objet HTTP fortement typé. Le même modèle de programmation HTTP est pratiquement disponible sur le client par l’intermédiaire de HttpClient pouvant être utilisé pour appeler des API Web dans n’importe quelle application .NET.

• Négociation de contenu : Le client et le serveur peuvent travailler ensemble afin de déterminer le bon format pour les données retournées à partir d’une API. Les formats pris en charge par défaut sont le XML et JSON. Le développeur pourra élargir ce soutien en ajoutant ses propres formats, ou même en remplaçant la stratégie de négociation du contenu par défaut.

• Prise en charge complète des routes : l’API Web prend désormais en charge l’ensemble des fonctionnalités de route qui ont toujours été une partie de la pile Web, y compris les paramètres d’itinéraire et les contraintes. En outre, la cartographie des actions possède un support complet pour les conventions, de sorte que le développeur n’aura plus besoin d’appliquer des attributs à une classe ou méthode. La configuration de Web API se fait uniquement à travers le code.

• Composition de requêtes : Web API permet de prendre rapidement en charge l’interrogation par l’intermédiaire des conventions URL OData. Lorsque le développeur retourne un type IQueryable de son API Web, le cadre fournira rapidement un soutien pour OData, rendant facile l’implémentation de la pagination et le tri.

• Validation des modèles : Le modèle fournit un moyen facile d’extraire des données de diverses parties d’une requête HTTP et de convertir ces parties du message en objets .NET, qui peuvent être utilisés par des actions Web API. Web API offre le même support qu’ASP.NET MVC pour la liaison des modèles et l’infrastructure de validation.

• Filtres : l’API Web permet de créer et utiliser facilement des filtres, qui permettent d’encapsuler et d’appliquer divers comportements.

• Améliorations des tests : plutôt que de fixer des détails dans les objets de contexte HTTP statiques, les actions Web API peuvent maintenant travailler avec les instances de HttpResquestMessage et HttpResponseMessage, deux nouveaux objets HTTP qui permettent d’effectuer plus facilement des tests.

• Support de l’IoC : Web API prend en charge le modèle de service de localisation mis en œuvre par ASP.NET MVC, qui permet de résoudre les dépendances pour de nombreux dispositifs différents. Le développeur peut facilement intégrer cela avec un conteneur IoC, ou un cadre permettant l’injection de dépendances.

• Flexibilité lors de l’hébergement : Web API peut être déployé dans n’importe quel type d’application ASP.NET (y compris à la fois ASP.NET MVC et ASP.NET Web Forms). Web API peut également être hébergé au sein de votre plateforme, si vous ne voulez pas utiliser ASP.NET/IIS pour le faire. Cela vous donne un maximum de flexibilité dans la façon dont vous l’utilisez.

Voyons de près quelques-unes de ces fonctionnalités au travers d’une application Web API.

Lors de la création d’un nouveau projet ASP.NET MVC 4, un nouveau modèle de projet est disponible dans les Templates par défaut qui fournit une implémentation basique d’une API Web.

Par défaut, un nouveau contrôleur Web API qui hérite de ApiController est disponible dans ce modèle de projet, qui illustre comment vous pouvez créer des requêtes Get(), Post(), Put() et Delete() pour votre API.

public class ValuesController : ApiController
    {
        // GET /api/values
        public IEnumerable<string> Get()
        {
            return new string[] { "value1", "value2" };
        }

        // GET /api/values/5
        public string Get(int id)
        {
            return "value";
        }

        // POST /api/values
        public void Post(string value)
        {
        }

        // PUT /api/values/5
        public void Put(int id, string value)
        {
        }

        // DELETE /api/values/5
        public void Delete(int id)
        {
        }
    }

Support complet des routes

Comme pour ASP.NET MVC, la définition des routes pour Web API est effectuée dans le fichier Global.ascx. Les routes pour Web API reprennent quasiment le même format que celle de MVC, afin que le développeur puisse capitaliser sur ses notions acquises.

En ouvrant donc le fichier Global.ascx, la route suivante est définie par défaut pour l’API Web :

routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );

A la différence de MVC, la route est ajoutée dans MapHttpRoute() et la méthode d’action n’est par définie dans le modèle de route. Ce qui implique que le développeur n’a pas besoins de spécifier une action. Web API identifie automatiquement la méthode du contrôleur qui sera exécutée en fonction du verbe HTTP qui est effectué (GET, POST, etc.).

Jetons un premier coup d’œil sur notre API Web en utilisant le contrôleur d’exemple (Values) inclus dans l’application pour avoir un aperçu du résultat qui est retourné.
Il suffit d’exécuter l’application et renseigner dans la barre d’adresse du navigateur l’URL suivant : « …/api/Values ».

Le résultat qui est retourné au format XML est le suivant :

<ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<string>value1</string>
<string>value2</string>
</ArrayOfString>

Passons maintenant à un exemple plus concret qui présente comment mettre en œuvre simplement des actions CRUD avec ASP.NET Web API.

Il est possible de créer un API controller avec par défaut les actions Read/Write. La boite de dialogue contient désormais un nouveau template pour la création d’un contrôleur qui hérite d’APIController avec des actions Read/Write.

Lorsque l’on crée un contrôleur en utilisant ce modèle, il contient par défaut les actions Get, Post, Put et Delete tel que mentionné ci-haut.

Ces actions peuvent être modifiées comme suit pour exposer les fonctionnalités CRUD de l’application directement à travers HTTP.

public class CustomerController : ApiController
    {

        private CustomerRepository repository = new CustomerRepository();
 
        // GET /api/customer
        public IEnumerable<Customer> Get()
        {
        
           return repository.GetAll();
        }

        // GET /api/customer/5
        public Customer Get(int id)
        {
            var customer = repository.Single(id);

           return customer;
        }

        // POST /api/customer
        public HttpResponseMessage Post(Customer customer)
        {
            Int id = repository.Add(customer);

            //spécification de l'emplacement du produit au Client REST
            var response = new HttpResponseMessage(HttpStatusCode.Created);
            response.Headers.Location = new Uri("/api/customer/" + id);

            return response;
        }

        // PUT /api/customer/5
        public void Put(int id, Customer customer)
        {
            var customeri = repository.Single(id);

            if (customeri == null)
                //Informe le client que la ressource n'existe pas
                throw new HttpResponseException(HttpStatusCode.NotFound);

            repository.SaveChanges(customer);
        }

        // DELETE /api/customer/5
        public HttpResponseMessage Delete(int id)
        {
            Customer customer = repository.Single(id);
            
            this.repository.Delete(customer);
            //Confirmation de la suppression au client 
            return new HttpResponseMessage(HttpStatusCode.NoContent);
        }
    }

Comme je l’ai signalé plus haut avec la négociation de contenu, Web API peut automatiquement sérialiser votre modèle aux différents formats qui sont supportés (JSON, XML, etc.) et ensuite écrire les données sérialisées dans le corps du message de la réponse HTTP. Le client peut desérialiser l’objet transmis par HTTP tant qu’il peut lire le format de sérialisation. La plupart des clients supportent par défaut le format XML et JSON.

- Appel du service avec JavaScript

Voyons maintenant comment appeler le service en utilisant JavaScript. Le script ci-dessous permet d’appeler le verbe Get pour lire les données.

<!DOCTYPE html>
<html lang="en">
<head>
    <title>ASP.NET Web API</title>
    <script src="../../Scripts/jquery-1.6.2.min.js" type="text/javascript"></script>
    <script type="text/javascript">
        $(document).ready(function () {
            // Envoi de la requête Ajax
            $.getJSON("api/Customer/",
            function (data) {
                // En cas de succès, 'data' contient la liste des clients.
                $.each(data, function (key, val) {

                         var str = val.Id + ' ' + val.FirstName + ' ' + val.LastName;

                         $('<li/>', { html: str }).appendTo($('#customers'));
                });
            });
        });
    </script>
</head>
<body>
    <div>
        <h1>Customers</h1>
        <ul id='customers' />
    </div>
</body>
</html>

En remplaçant le code de la page Index.cshtml de mon application par celui ci-dessus, j’obtiens le résultat suivant dans mon navigateur :

– Utilisation de HttpClient

Il est également possible d’utiliser la Classe HttpClient pour accéder à une WebAPI dans n’importe quelle application .NET (WebForms, MVC, WinForms, Console, etc.). Elle permet d’effectuer avec souplesse des appels HTTP en utilisant les méthodes GetAsync, PostAsync, PutAsync, DeleteAsync qui vont appeler les verbes Get, Post, Put et Delete.

Exemple :

HttpClient client = new HttpClient();
            client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/xml"));
            var response = client.GetAsync("http://localhost:1369/api/Customer").Result;

Pour spécifier que les données retournées doivent être au format JSON, on peut procéder comme suit :

HttpClient client = new HttpClient();
            client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
            var response = client.GetAsync("http://localhost:1369/api/Customer").Result;

L’intégration d’ASP.NET Web API dans ASP.NET MVC 4 est vraiment fluide et permet au développeur de capitaliser sur ses acquis pour facilement exposer les fonctionnalités de son application via HTTP.

Ressources sur WebApi

– Henrik F Nielsen
– Les ressources Web API sur ASP.NET

En dehors des nouveautés disponibles dans la version Developper Previw publiée en septembre dernier dont le support des plateformes mobiles, le rendu adaptatif, View Switcher, des nouveaux modèles de projet Web, etc. la bêta apporte plusieurs corrections de bug et quelques nouveautés donc la plus importante est l’introduction de l’API Web.

L’API Web

Web API a fait son apparition dans WCF. Elle a pour objectif principal de permettre aux développeurs d’exposer leurs applications, données et services sur le web directement à travers HTTP.

Au vu des besoins d’interaction de plus en plus croissants entre une application Web et un ensemble très large de clients (réseaux sociaux, navigateurs, terminaux mobiles, etc.), il était indispensable de fournir aux développeurs un moyen de communiquer dans leurs applications avec ces différents types de clients. Pour ne pas avoir à développer deux outils différents permettant d’effectuer les mêmes actions, l’équipe d’ASP.NET MVC c’est chargée d’intégrer WCF Web API avec le Framework de développement qui devient Web API.

Regroupement par défaut

Depuis la Developer Previw d’ASP.NET MVC 4, la librairie Microsoft.Web.Optimisation avait été introduite à la plateforme, ainsi qu’a ASP.NET 4.5, pour permettre d’optimiser les performances d’une application et améliorer le temps de chargement des pages en utilisant le regroupement et la minification à la volée du JavaScript et CSS.

Avec la bêta de MVC 4, le regroupement est utilisé par défaut dans les modèles projets Web. A l’ouverture d’un Template, vous trouverez dans le fichier Layout les lignes de code suivantes dans la balise Head :

<head>
        <meta charset="utf-8" />
        <title>@ViewBag.Title - My ASP.NET MVC Application</title>
        <link href="~/favicon.ico" rel="shortcut icon" type="image/x-icon" />
        <link href="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Content/css")" rel="stylesheet" type="text/css" />
        <link href="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Content/themes/base/css")" rel="stylesheet" type="text/css" />
        <script src="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Scripts/js")"></script>
        <meta name="viewport" content="width=device-width" />
    </head>

Pour plus de détail sur l’utilisation du regroupement et la minification du JavaScript dans une application Web, voir mon article sur le sujet.

Améliorations de Razor

Le moteur de vue Razor qui à fait son apparition avec MVC 3, croit en maturité dans cette version, avec des améliorations qui simplifient sa syntaxe dans certains scénarios courants.

– Résolution d’URL : prise en charge de « ~ » dans la syntaxe.

Désormais au lieu d’écrire :

<scriptsrc="@Url.Content("~/Scripts/Site.js")"></script>

Le développeur pourra écrire :

<scriptsrc="~/Scripts/Site.js"></script>

– Rendu conditionnel d’attribut

Précédemment, si vous vouliez utiliser un attribut qui peut-être nul, vous deviez vérifier au préalable si celui-ci n’est pas vide avant de l’utiliser.

<div@{if (myClass != null) { <text>class="@myClass"</text> } }>Content</div>

Désormais, Razor est capable de gérer cela automatiquement, de telles sortes que vous pouvez directement l’utiliser. Si l’attribut est vide il ne sera simplement pas appelé.

<div class="@myClass">Content</div>

Si l’attribut est donc nul, le rendu de code sera le suivant :

<div>Content</div>

Utilisation de NuGet pour installer les bibliothèques externes des modèles de projet

Avec la bêta de MVC 4, lorsque que vous créez un nouveau projet, les packages sont installés dans l’application en utilisant NuGet package restore. Le package NuGet restore permet lors de la compilation ou de la création d’une application, de vérifier si les packages présents correspondent aux dernières versions publiées. Si ce n’est pas le cas, il se charge automatiquement d’effectuer la mise à jour.

ASP.NET MVC 4 peut-être utilisé avec Visual Studio 2010 Service pack 1 ou Visual Web Developer 2010 Service Pack 1. La préversion de Visual Studio 11 n’est pas prise en charge.

Le framework peut s’installer via NuGet ou en utilisant le Web plateforme installer. Les binaires sont également disponibles en téléchargement.

Je reviendrais sur une présentation plus détaillé de Web API dans un prochain billet de blog.