ASP.Net MVC 6

ASP.Net MVC 6

ASP.Net MVC 6

ASP.NET MVC 6 est la nouvelle version du Framework MVC de .NET. Il a pour vocation de tirer partie de la puissance de .NET tout en mettant de côté l'historique parfois pesant d'ASP.NET. Venez découvrir en quoi ASP.NET MVC 6 est un framework MVC moderne et les principales nouveautés de cette nouvelle version majeure


Part de l'initiative ASP.NET vNext, ASP.NET MVC 6 représente un changement fondamental pour Microsoft dans sa façon de construire et de déployer ses frameworks Web. L'objectif est de créer un framework agnostique de l'hôte qui élimine les dépendances avec l'infrastructure historique System.Web.

Microsoft ressent le besoin de supprimer System.Web car celui-ci représente un coût relativement important. Un graphe d'objet HttpContext classique peut consommer jusqu'à 30K de mémoire par requête et lorsque l'on se contente de travailler avec des petites requêtes, à base de JSON par exemple, ceci représente un coût disproportionné. Avec la nouvelle conception d'MVC 5, le surcoût à la requête descend à près de 2K.

MVC 6 inclut Web API et Web Pages, ce qui permet à Microsoft de supprimer une bonne part du chevauchement entre les trois frameworks. Résultat de ces modifications, MVC sera auto-hébergé, au même titre que Web API 2 et SignalR 2.

Afin de rendre les déploiements plus faciles et plus fiables, "vNext supportera un vrai déploiement side-by-side". Plutôt que de s'installer dans le GAC, chaque librairie MVC nécessaire à un site donné sera référencée comme une DLL classique, comme celles créées par les développeurs. "Ceci signifie que vous pouvez mettre à jour votre application sans affecter d'autres applications sur le même serveur".

Payez pour ce que vous utilisez

MVC 6 est construit sur une philosophie "payez pour ce que vous utilisez", "pay as you go". Chaque fonctionnalité que vous souhaitez utiliser doit explicitement être activée dans la routine de démarrage de l'application. Même le fait de servir des fichiers statiques requiert un appel à IBuilder.UseStaticFiles. Ceci fonctionne de la façon suivante : chaque site Web doit avoir une classe nommée Startup avec une méthode "void Configure(IBuilder app)". À l'intérieur de cette méthode, vous pouvez appeler des fonctions comme "app.UseServices" pour activer des fonctionnalités telles qu'MVC. Le routing est défini dans la méthode Configuration. Les routes MVC 6 sont similaires (pas identiques) aux routes MVC 5. Par exemple, un point d'interrogation peut être ajouté à un fragment pour le rendre optionnel. Avec MVC 5, il était nécessaire d'utiliser la valeur UrlParameter.Optional pour obtenir le même résultat.

Déploiements Azure et PowerShell

Microsoft pousse toujours Azure comme standard de déploiement des sites Web. Mais Microsoft a réalisé que les développeurs peuvent être réticents à publier directement depuis Visual Studio. À la place et par défaut, donc, des scripts de déploiement PowerShell sont générés. Ces scripts peuvent être édités dans Visual Studio, qui est maintenant équipé de l'outillage de base pour supporter PowerShell.

Le processus de Build ne construit pas

Avec ASP.NET vNext, le processus de Build ne construit rien du tout, en réalité. Aucun binaire n'est généré. Il exécute simplement la vérification de type pour s'assurer qu'il n'y a pas d'erreur ou de warning à traiter. À la place, le code est compilé à la volée, au besoin, à la manière d'ASP.NET Web Pages. Ceci permet des itérations plus rapides, en particulier sur les sites de taille importante. Si vous avez besoin que des binaires soient déployés sur un serveur, il vous faudra exécuter la commande package and publish. Ceci offrira plusieurs options, allant du code source uniquement, qui continuera à se compiler à la volée, jusqu'à des versions compilées natives. Cette dernière donnera très probablement de meilleures performances mais nécessitera un processus de Build plus long.

De nombreuses API déplacées ou supprimées

Comme mentionné plus haut, la taille d'HttpContext sera réduite de 30K par requête à quelques 2K par requête. Le prix à payer pour cela est un ensemble de méthodes disponibles réduit de façon significative sur cet objet et ses enfants. D'ici à ce que tout soit finalisé, il y aura probablement d'autres coupes dans les API. Afin de rendre cette transition moins fastidieuse, il est prévu de développer un outil similaire à FxCop qui détectera les appels aux anciennes API. Même si celui-ci ne sera pas capable de réécrire votre code automatiquement, l'outil pourra au moins indiquer quels changements sont nécessaires avant migration vers ASP.NET vNext et MVC 6. Parfois, ce changement impliquera uniquement l'appel d'une méthode différente, depuis un package ou une librairie optionnelle. D'autres fois, le code devra être revu de façon significative. Le produit étant encore en version alpha, la liste complète des changements n'est pas disponible actuellement.

Framework complet vs Framework optimisé pour le Cloud

Les avertissements ci-dessus sont à prendre en compte à cause de la suppression de System.Web. À côté de cela, vous pouvez rester sur le Framework .NET complet. Si vous souhaitez franchir l'étape suivante vers ce qu'on appelle le Cloud Optimized Framework, alors vous perdrez l'accès à encore d'autres API. Lors de la session de Q&A sur Channel 9, System.Drawing a été donné comme exemple de ce que vous ne pourrez plus utiliser. L'avantage d'utiliser le Cloud Optimized Framework est que vous pouvez inclure une copy du Core CLR (ou Mono) dans votre projet. Vous n'avez plus à mettre à jour .NET sur toute la machine pour les seuls besoins d'un unique site Web. Vous pouvez même avoir plusieurs versions de la CLR exécutées côte à côte, pour différents sites.

 

Librairies vs Packages

Avec le modèle .NET vNext, les projets ne référencent plus les librairies de façon individuelle. À la place, ce sont des Packages NuGet qui se retrouvent référencés. Comme vous devez le savoir, les packages peuvent contenir plusieurs versions d'une librairie, divisées par plate-forme cible. ASP.NET vNext peut mettre cela à profit pour décider à runtime s'il faut charger la version Full .NET, Mono ou Core CLR d'une librairie donnée.

Si cela ne vous semble pas convenable, vous avez toujours la possibilité d'utiliser les Portable Class Librairies. Bien que tout ne soit pas encore prêt, il est prévu de créer un profil PCL pour le Cloud Optimized Framework.

Support de Mono

Dans le passé, le discours au sujet de Mono était essentiellement "nous espérons que ça fonctionne, si ça n'est pas le cas, voyez avec Xamarin". À présent, Microsoft annonce Mono comme étant l'officielle cross-platform CLR pour ASP.NET vNext. À cet effet, Microsoft travaille activement avec les équipes Mono pour s'assurer qu'elles ont tout ce dont elles ont besoin et incluront Mono dans leurs tests d'intégration continue.

Ceci dit, Microsoft n'offre pas de support officiel pour Mono via leurs canaux de support payant. Ils se contentent de promettre de maintenir la compatibilité et, si un test d'intégration continue échoue, qu'ils travailleront avec les équipes Mono pour le réparer.

Développement Cross-Platform

Microsoft prévoit non seulement un déploiement cross-platform mais aussi un développement cross-platform. Des fichiers batch pour toutes les plate-formes majeures comme OS X et Linux seront fournis afin de permettre de packager et de déployer les projets ASP.NET vNext sans avoir besoin de Windows et de Visual Studio.

Les modules KPM, "Katana Packages Modules", inspirés des modules node.js, les Node Packaged Modules, sont inclus également. Katana a été un projet de recherche visant à modulariser ASP.NET MVC pour son utilisation sur Owin. KPM s'appuiera sur les repositories NuGet.

 

ASP.Net MVC 6 apporte énormément de changment par rapport à son prédécesseur, afin d'être rapidement opérationnel sur ses nouveautés inscrivez-vous à la formation ASP.NET MVC 6

 


Cette actualité a été postée avec les tags asp mvc, C#, dot net

Catégories

Articles récents

Tags

android Android angular angular-cli angular-cli azure stack C# cloud dot net ios IOS javascript material mobile rxjs typescript Visual-Studio web windows mobile Xamarin .Net angular angular js asp mvc azure javascript material xaramin