Choses et autres

Retour sur OWIN

Retour sur OWIN

Pour ceux qui n'ont pas encore eu l'occasion de suivre l'évolution du projet, OWIN (Open Web Interface for .NET) est un middleware (essentiellement, se situe entre le serveur web (IIS, Kestrel, nginx, apache et autres) et votre application. Son role est donc d'exposer de façon standard les requêtes et réponses.

Pourquoi ?

En fait, OWIN a pour source entres autres les framework Rack (de ruby) et WSGI (de python). Le but était à l'origine de faire une séparation entre IIS et l'application afin de permettre que l'évolution du framework MVC et du serveur web IIS se fasse de façon indépendante l'un de l'autre (puisque MVC était très limité par la lenteur des releases de IIS, qui viennent avec Windows).

Owin offre en outre une façon plus aisé et flexible (et surtout testable) d'exposer des modules au sein de l'application. Il est à noter également que à partir de vNext Owin étant le centre de l'application, System.Web ne seras plus chargé à chaque requête. L'effet direct est une performance théorique accrue (par un facteur de 10 selon les benchmarks de Microsoft) et une consommation de mémoire énormément réduite (de 96% environs).

Utilisation

OWIN remplace la classe Global à terme. Par convention, OWIN cherche pour une classe nommée Startup (dans n'importe quel namespace).

Un exemple simple ressemblerait à ceci, pour chaque requête peu importe son contenu, répondre “Hello World”:

using Microsoft.AspNet.Builder; // pour IApplicationBuilder
using Microsoft.AspNet.Http; // Pour la méthode d'extension app.Run()

namespace Builder.HelloWorld.Web
{
    // Marque la classe comme étant le point de départ
    public class Startup
    {
        // appelé lors du démarrage de l'application
        public void Configure(IApplicationBuilder app)
        {
            // déclaration d'une lambda appelée pour chaque requête
            app.Run(async context =>
            {
                context.Response.ContentType = "text/plain";
                await context.Response.WriteAsync("Hello world");
            });
        }
    }
}

Pas plus compliqué que ça. Ces quelques lignes peuvent suffire à écrire une application (basique) en utilisant owin.

Utilisation simple au sein de MVC

using Microsoft.AspNet.Builder; // pour IApplicationBuilder
using Microsoft.Framework.DependencyInjection; // pour l'injection de dépendances

namespace TagHelperSample.Web
{
    // Marque la classe comme étant le point de départ
    public class Startup
    {
        // appelé lors du démarrage de l'application
        public void Configure(IApplicationBuilder app)
        {
            // configure les services d'injections de dépendances 
            // pour utiliser et injecter Mvc
            app.UseServices(services => services.AddMvc());

            // configure le module MVC avec les routes par défaut
            app.UseMvc();
        }
    }
}

Puisque la nouvelle tangente de l'équipe asp.net était de moderniser les techniques de développement, MVC fonctionne maintenant par IOC (Inversion de Contrôle) et se fait injecter au sein du système maintenant. Double avantage lié au contrôle mais également par le fait que ça permets de remplacer MVC très aisément par NancyFX par exemple. Il est aussi possible de rouler MVC et NancyFX en parallèle d'ailleurs

namespace MyApplication
{
    using Microsoft.AspNet.Builder;
    using Nancy.Owin;

    public class Startup
    {
        public void Configure(IBuilder app)
        {
            app.UseOwin(x => x.UseNancy());
        }
    }
}

Plus de d'information

Introducing ASP.Net Project Helios (en)
Future of .Net on the server (en)
Deep Dive the future of .NET on the server (en)

Project K le nouveau AspNet

Project K le nouveau AspNet

Le 18 mai dernier à TechEd (Houston, Tx), nous a été présenté la prochaine version de AspNet (vnext). La nouvelle vision s'en vas vers un framework intensément allégé et j'ai l'intention d'écrire quelques billets sur la question considérant le sérieux et la plus grande stabilité du projet actuel.

Qu'est-ce que Project K

Le K dérive de Katana qui étais à l'origine un nouveau module faisant parti du projet Helios, qui avais pour but de découpler le serveur web des applications web. Il était formé du couple OWIN (Open Web Interface for .NET, un middleware étant entre le serveur web et l'application) et Katana (une interface exposant des propriétés standards liés aux serveurs web pour parler avec owin). En fait on peut faire un rapprochement avec le framework Rack de Ruby

Pourquoi Project K ?

En fait, le web étant ce qu'il est, il est extrèmement rapide au développement, il est normal qu'une brique plus monolithique (comme l'était le System.Web) pouvais poser problème dans la mesure où chaque nouvelle version était déjà dépassée. De plus, l'assembly étant assez massive, il était inutile de prendre tous les composants pour chaque utilisation. Par exemple cet assembly était responsable de :

  • HttpRuntime.Cache
  • System.Web.Routing
  • Attaches vers IIS (Microsoft.Runtime.Hosting)
  • Membership et Profile
  • WebForms
  • System.Web.WebSockets

Ceci n'étant qu'un petit exemple des responabilités, on peut rapidement voir que cette assembly était énorme sans justification certaine.

Nouveautés

Project K arrive donc avec son lot de nouveautés :

  • Tout le stack ASP.Net est maintenant open sourcé sur github
  • KVM (pour K Version Manager, un gestionaire de version de .net framework)
  • KPM (pour K Package Manager, essentiellement l'équivalent de publish dans Visual Studio)
  • K (essentiellement un lanceur d'application, un peu comme Thor ou Rake dans l'univers Ruby)
  • Asp.Net MVC 6
  • Nouveau système de projet (fini les .csproj, apparament une nouvelle extension vois le jour : .kproj)
  • Fin du Global.asax et début du Startup.cs en tant que citoyen de première zone
  • Injection des dépendances en tant que citoyen de première zone (il était temps!)
  • Complète modularité du stack MVC (il est facilement possible par exemple de remplacer le fameux Yellow Screen of Death)
  • Fusion des frameworks MVC, WebAPI et WebPages (pages Razor)
  • Intégration native de Roslyn pour effectuer une compilation à la volée
  • Unification des framework MVC, WebAPI et WebPages (Razor)
  • Intégration de mono en tant que citoyen de première zone (ça c'est impressionant)
  • De plus, point intéressant intéressant il n'est plus requis d'utiliser Visual Studio pour le développement (le fichier project.json semble gérer la compilation et les dépendances)

Depuis quelques temps Project K est supporté officiellement par Visual Studio via Visual Studio 2014 CTP (Community Technology Preview) dont la 3e version est sortie tout récemment le 18 août).

Plus d'informations

  • MVC Les nouveautés
  • KVM et son utilisation
  • KPM pour le publish et son implication
  • Retour sur Owin et son utilisation
  • Startup.cs le remplacement du Global.asax
  • Injection de dépendances
  • Entity Framework 7

Outlook et alias dynamiques

Petite trouvaille sympathique de la journée: Gmail et Outlook offrent tous les deux la possibilité d’avoir des alias dynamiques.

Par exemple, assumons que votre courriel est “truc@outlook.com” ou “truc@gmail.com”.

Si vous ajoutez un + à votre préfixe d’adresse courriel (truc dans ce cas présent) il est possible de créer un alias qui envoie le courriel à votre boite aux lettres.

Donc : truc+twitter@outlook.com s’envoie à truc@outlook.com.

Ainsi il est facile de créer des règles dans la boite courriel pour déterminer l’origine d’un courriel et dans le cas de spam si celui ci est envoyé à “truc+twitter@outlook.com” on peut voir donc que c’est twitter qui aurait vendu votre adresse courriel à des spammers.