jeudi 3 novembre 2016

ASP.NET Core MVC AutoPostBack dropdownlist TagHelper

Si vous avez commencé à jouer avec ASP.NET Core MVC, vous avez probablement commencé à utiliser les TagHelpers, car c'est vraiment une fonctionnalité GENIALE.

La problématique


Pour le développement d'un site, j'ai dû intégrer la "Localisation" (inspiré de l'excellent article de Andrew Lock) et permettre à l'utilisateur de changer de langue sur le site.


Dans l'exemple qui suit, on est obligé de cliquer sur le bouton "OK" pour poster le formulaire de validation du choix de langue et cela n'est pas très ergonomique. Mon intention est donc de changer  la langue au moment où l'on choisit un langue dans le menu déroulant, sans trop modifier le code existant :




Le fait est que dans notre cas, j'utilise un composant "select" avec des "TagHelpers" et je ne souhaite surtout pas modifier ce composant très pratique. Comment faire donc pour avoir mon autoPostBack sur ce composant ?

Une solution possible


J'ai opté pour une solution assez simple à l'aide du bon vieux JavaScript :



J'ai rajouté une action "onchange" sur mon composant Html, suivi d'un simple "submit" de mon "form" car au final, c'est bien ce que faisait mon bouton "Ok" que je souhaitais supprimer.
Et voilà, le tour est joué.
Comme d'habitude, si vous avez des solutions alternatives et meilleurs, je suis preneur.

lundi 31 octobre 2016

Démarrer un site avec ASP.NET Core avec un code legacy en .NET classique (.NET Framework)

On arrive bientôt à la fin d'année 2016 et .NET Core est loin d'être finalisé. Cependant, on peut déjà s'aventurer sur cette nouvelle plateforme même si on a un code existant.

Configuration adaptée
Visual Studio 2015 update 3




L'idée ici est de ne surtout pas se tromper lors du choix du template ASP.NET Core : Au moment de créer votre nouveau site Asp.net MVC core, il faudra sélectionner le template ciblant le framework .NET et  non .NET Core (cf l'image ci-dessous). Cela nous vous permettra de pouvoir reférencer vos projet (dll) existants qui ne sont pas en .NET Core.



A noter également l'importance de la version cible : ici la version du framework est la 4.6.1. Il faudra donc idéalement que tous mes projets existants soit compilés sous la même version (4.6.1 donc) que mon site web, afin de pouvoir les référencer.
Dit comme ça, cela peut paraitre évident, mais vous verrez qu'au quotidien, tout un ensemble d'erreurs seront dûes aux imcompatibilités de version de framwork de vos projets existants et nouveaux.

Je crée ensuite mon application web avec le template Web Application, sachant qu'une des nouveautés intéressante avec .NET Core c'est que la partie Web API est fusionnée (au niveau des controlleurs).






Dans le fichier project.json de notre application Web Core, on voit bien que le framework cible est uniquement : net461; sachant qu'on pourrait "targeter" plusieurs frameworks dans l'absolu.



A date, le tooling ainsi que les librairies disponibles en .net Core pure ne sont pas encore finalisés.

Reférencons maintenant une librairie existante (de notre code legacy) en faisant "clique droit" sur "références" dans notre projet web, puis "Add reference...". Regardons maintenant dans notre project.json du projet web :



Notre projet "MyProjectServices" est bien reférencé sans problème. A noté que ce projet de classe cible bien le framework 4.6.1.

Projet de Test unitaires

Ajoutons un projet de tests unitaires :


A l'identique du projet ASP.NET Core, on cible bien le framework 4.6.1. Afin de pouvoir rentre compatible le projet de test au projet ASP.NET Core, on crée un projet de classe ".NET Core".
En essayant de rajouter en référence le projet web, nous obtenons le message d'erreur suivant :


C'est pour évider ce type d'erreur de référence qu'il faut être vigilant à propos des versions de framework des différents projets.

Nous allons modifier le fichier project.json du projet de classe en '"Core" que nous venons de créer afin de le rendre compatible et utilisable comme projet de tests unitaires.


Comme pour les autres projets encore une fois, nous utilisons le même framework cible "net461". On rajoute également les dépendances au framework de test XUnit et on spécifie également le "runner" associé. Une fois le "restore" de nos packages effectués, l'ajout de reférence du projet web s'effectue sans problème.


En créant un premier test unitaire de controller, on résout les dépendances sans problème, et l'exploirateur de tests reconnait bien et affiche tous nos tests.
Voilà à quoi ressemble notre project.json du projet de test au final :


En conclusion,
Nous avons donc un projet ASP.NET Core ciblant le framework 4.6.1, qui peut reférencer des librairies de classes sous le même framework, ainsi qu'un projet de test compatible pour notre projet ASP.NET Core. Nous n'avons donc pas besoin de reécrire nos librairies et packages en .NET Core grace au mécanisme précédemment utilisé. Cela nous permettra donc de nous amuser avec les nouveautés ASP.NET Core MVC pour la partie Web, utiliser nos librairies métiers et transverses existantes, tout en préparant une transition en douceur sans tout casser dans nos solution existante.


dimanche 28 février 2016

Un site web ASP.NET MVC 5 de A à Z - Le M le V et le C

Avant de rentrer dans le vif du sujet nous allons parler du model MVC et faire un tour d'horizon sur ses 3 composants à savoir :

  • le Model (model)
  • la Vue (view)
  • le Controlleur (controller)


Le MVC c'est avant tout un pattern (un design pattern à la base) orienté Web.  L'idée est d'organiser le code de façon à ce qu'il soit plus maintenable, testable, et que chaque partie soit plus ou moins autonome avec une resposabilité précise, afin de diminuer le couplage entre composant.
Il faut donc comprendre que le MVC c'est avant tout conceptuel : c'est à dire que chaque composant, selon les langages, et la façon dont on décide de l'implémenter présentera des nuances mais l'idée maitresse reste la même :

  • Le controlleur a pour mission principale d'envoyer à l'utilisateur la vue contenant une composition d'un ou plusieurs model.
  • La vue représente ce qui va être renvoyé à l'utilisateur : au niveau Web c'est le contenu Html (ou autre ressource demandé par l'utilisateur) affiché en règle générale. Les vues peuvent être organisées et divisées en vues partielles.
  • Le modèle représente les données qui seront associés et affichées au niveau des vues. On parle également de View Model pour "typer" fortement le modele à une vue précise


Même si le controlleur peut renvoyer autre chose que des vues comme par exemple du json brut, il demeurt que sont rôle principal et de préparer la vue à afficher : il consolide donc les données à partir de model(s)  servant de "gabarit" de données et via des règles métiers provenant de composants dédiés (services externes/web service, couches techniques tiers, etc).
En effet, même si on peut facilement implémenter les règles métiers au niveau du controlleur, il est plus judicieux de le faire dans un composant décorelé, afin justement de bien séparer les rôles.

Jusque là, on est au niveau théorique : dans la pratique, et plus précisement en ASP.NET MVC, c'est beaucoup plus compliqué que cela :
on a au départ une requête effectué par un utilisateur via une URL saisi dans son navigateur. Entre la résolution DNS (et toutes la partie traitement réseau que je vous épargne ici) et retour du serveur répondant web répondant à la requête, il va se passer tout un tas de choses. On parle souvent de cycle de vie ou de pipe Line de la requête.
Voici en image (trouvé sur dotnetcurry) ce qui se passe de façon macro :



Voici ce qui se passe si l'on regarde de plus près :



Les grandes étapes du traitement de la requête sont donc :

  • le routing (Routing) 
  • interception de la requete pas le module de routing 
  • execution du handler MVC
  • execution du controlleur
  • rendue de la vue
Il n'est pas obligatoire de comprendre le fonctionnement interne du cycle de vie MVC en .NET, par contre vous allez vite vous y interessé quand vous allez passer à la pratique, notamment quand vous serrez confronter à certaines problématiques de sécurité, de gestion d'url, etc. Il veux mieux donc comprendre un minimum par où passe ma requête, ce qui se passe, et comment le résultat m'est rendu.

jeudi 31 décembre 2015

Un site web ASP.NET MVC 5 de A à Z - Initiation au versionning avec Git (partie 2)

Dans notre article précédent, nous avions vu comment utiliser Git dans notre projet avec Visual Studio. Cette fois-ci nous allons voir comment mettre en place une STRATEGIE DE BRANCHES : il s'agit en réalité de mettre en place un vrai processus de gestion de branches qui s'inscrit dans une optique DevOps.


Pourquoi mettre en place une stratégie de branches ?

Pour répondre à cette questions, voici d'autres questions qui font office de réponse :

  • Comment travailler à plusieurs sur le projet sans collision ?
  • Comment je sais quelle version de mon application est en production ?
  • Comment je vois l'historique de mon application ?
  • Comment je reviens à une version précédente (rollBack) ?
  • comment je fais si j'ai un bug en Production ?
  • Comment je fais pour livrer une évolution sans embarquer celle de mon collègue ?
  • Comment je récupère les évolutions de mon collègue X sans celle de mon collègue Y ?
  • Comment je travaille proprement avec des collègues qui travaillent sur le même projet depuis un autre site ou autre pays ?


Stratégie de branches avec Git

Il existe une multitude de stratégie de branches existantes et ayant fait leur preuve. Il faut cependant admettre que chaque projet à ses spécificités et il convient d'adapter sa stratégie pour faciliter au mieux le travail des développeurs/ops/testeurs.
L'exemple ci-dessous est celui que j'utilise le plus souvent :





source : http://nvie.com/posts/a-successful-git-branching-model

L'idée de ce système de branching est de "tirer" une branche pour chaque feature (fonctionnalité à développer). En plus, des branches plus "stables" doivent exister pour gérer le cycle de vie de l'application :

  • la branche master : elle sert de versionning pure des versions livrées en prod. A chaque déploiement en production, un merge doit être fait sur cette branche depuis la branche "release" ainsi qu'une apposition de tag Git qui sert d’étiquetage de la version.
  • la branche release : c'est la branche source de livraison. Une fois les devs des features terminés, on merges toutes les features branches vers la branche develop. De la branche develop, on merge vers la branche 'release' pour une MEP à venir.
  • la branche hotfixes : comme son nom l'indique, elle sert à patcher en production. Ainsi lorsqu'un bug critique/majeur apparaît en production et que l'on souhaite le corriger sans impacter les dev en cours, on utilise cette branche. un merge est alors effectué depuis la branche.
  • la branche develop : cette branche sert de merge des branches de features développé. c'est en quelque sorte la branche mère des devs en cours. Une fois les devs des features terminés, les branches de feature sont mergées vers la branche 'develop'. Une fois les 'merges' effectués, c'est de cette branche qu'on mergera vers la branche 'release'.
  • les branches de  feature : Git propose une grande souplesse en terme de branching. Ainsi, pour chaque User Storie que vous vous attribuez en début de sprint, vous pouvez tirer une branche à partir de 'develop'. Cette branche servira de développement de votre US, que vous pourrez remerger vers 'develop' une fois le développement terminé. Il arrive souvent qu'un développeur ait besoin de partager son dev avec un autre : dans ce cas, il peut merge sa branche vers 'develop' s'il estime que son développement est assez abouti et l'autre développeur pourra récuperer les modifications merger. Avec Git, un merge pourra être fait également d'une branche de 'feature' d'un développeur vers une autre branche de 'feature'.

Dans tous les cas, vous l'aurez certainement deviné, l'aspect collaboratif reste primordial. Il convient de communiquer le plus possible avec vos collègues afin de faciliter les 'merge' et la gestion de vos branches.

lundi 30 novembre 2015

Un site web ASP.NET MVC 5 de A à Z - Initiation au versionning avec Git (partie 1)

Lors du précédent article, nous avions initié notre projet ASP.NET MVC 5. Au passage nous avions également choisi comme controleur de code source GIT. Dans le cas de cette série d'articles j'utiliserai la plateforme Github pour versionner mon code source.

Pourquoi un contrôleur de code source dès le début du projet ?

Le contrôleur de code source est essentiel pour gérer notre projet web quelque soit sa taille. Tout d'abord, un projet ne se fige très rarement : il y a toujours un moment ou on fait le évoluer : par exemple, on décide de rajouter une nouvelle page web, changer le style, faire des évolutions plus approfondies comme par exemple rajouter/modifier/supprimer une partie du code métier (une nouvelle règle imposée par notre client). Un projet informatique (web dans notre cas) vie : il faut qu'à tout moment on sache on est et d'où on vient. Notre contrôleur de code source va donc archiver pour nous notre code et surtout garder une trace de toutes les actions que l'on effectue dessus.
Mieux encore, imaginons qu'un nouveau développeur arrive sur le projet : on va potentiellement travailler sur le même bout de code : comment savoir donc ce qu'il aurait effectué comme changement lors de mon absence ? Imaginons qu'après avoir livrer en Production (environnement final utilisé par les utilisateurs cibles), on se rend compte qu'il y a un bug grave sur une page ou une régression (une fonctionnalité qui marchait jusque là) : que fait-on ? on devrait donc pouvoir revenir une version plus récente (RollBack).
Vous l'aurez compris, il vaut avoir dès le départ de notre projet au minimum un contrôleur de code source afin de tracer toutes les actions effectuer sur notre code.

Quel contrôleur de code source pour votre projet ?

Il existe une multitude de contrôleur de code source : Git, Source Safe, TFS, SVN, ...
TFS (Team Foundation Server) fait office de contrôleur de code source mais peut également utiliser Git comme contrôleur, car TFS est une plateforme plus large proposant d'autres services tels que la gestion de build continue, gestion de projet via des tableaux de bord (Scrum, Kanban), etc.
Si vous travaillez sous les technos Microsoft et que vous disposez des licences TFS, c'est la solution par excellence. Vous pourrez choisir Git comme contrôleur de code source (même avec TFS).
Git est de plus en plus répandu du fait de sa puissante : il est simple d'utilisation (de prime abord), et rapide, il dispose d'un gestionnaire de code via ligne de commande et est disponible sur toutes les plateforme (Windows, Linux, Mac). Git est également gratuit : ce qui en fait un avantage non négligeable.


Git dans notre projet
Lorsque l'on regarde dans notre répertoire de solution on retrouve un dossier caché '.git' qui nous indique la prise en en charge par le controleur de code source.


lorsqu'on ouvre la solution dans Visual Studio, nous pouvons accéder à notre gestionnaire de code source via l'onglet "Team Explorer", et cliquer sur la "prise électrique verte" pour se "plugger" à une git par exemple.




Dans mon cas présent, je vais me connecter à "Github". Il vous faudra au préalable vous créer un compte gratuitement sur Github.com.





On constate ici sous le volet 'Référentiels Git locaux' que notre solution est mapper en local (nous y reviendrons plus tard), en double cliquant sur notre solution mappé, une nouvelle fenetre s'affiche nous permettant de "pousser" notre code vers le serveur Git.



Cependant, n'ayant pas encore créer de "Repository distant" (en gros, c'est la référence de notre arborescence sur le serveur Git), il va nous falloir le créer : on peut le faire depuis le site de Github directement :


Une fois le "Repository" crée, on peut récupérer son Url et la saisir sous Visual Studio afin d'effectuer le mapping.


Une la connexion établie avec le serveur Git, nous allons pousser notre code sur le serveur. Pour cela, nous retournons dans notre explorateur de solution, puis nous "validons" dans un premier temps la connexion de notre solution. Une nouvelle fenêtre nous demandera d'effectuer un "push" (valider la première fois) et/où "sync" : le sync récupère également les éventuelles modifications effectuer sur le serveur par un autre utilisateur par exemple, ou depuis un autre Pc.


une fois que vous lancer la synchronisation, votre code sera publier sur votre "Repository distant". Votre première action est donc historisée et apparaît dans votre éditeur.


Dans cette première partie, nous avons juste vu comment se connecter à un "Repo distant". Cependant, nous n'avons pas encore définit de stratégie de "branching" : en Effet, comment fait-on si on travailler à plusieurs et sur des évolutions différentes ? Comment fait-on un "hotfix" en Prod ?
Nous verrons cela dans mon prochain article.

PS : Une petite vidéo intéressante sur Git :
https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Getting-Started-with-Git
Un lien intéressant su Git :
http://pcottle.github.io/learnGitBranching/

samedi 3 octobre 2015

Encodage en BASE64 des images avec Web Essentials 2013


Les ressources chargées pour une page web sont parfois nombreuses (images, javascipt, css,etc) et peuvent pénaliser le serveur. : il est globalement conseillé de réduire la quantité de requêtes http pour une page web dans un but d'optimisation globale de votre application web.

Pour les images, il existe une multitude de techniques pour les optimiser : les Sprites, réduction de la tailles des images, et l'encodage en BASE64 des images. C'est du dernier point que je vais vous parler :

l'Encodage en BASE64 d'images
Il s'agit simplement de transformer (encoder) son image sous forme de texte qu'on utilisera directement dans nos css par exemple : du coup, on économise une requête de chargement d'image, cette dernière étant directement encoder dans le fichier css (où dans le "src" d'une balise "image").

l'Encodage BASE64 d'images dans Visual Studio 2013 avec Web Essentials 2013
L'extension Web Essentials 2013 propose les 3 optimisations d'images que j'ai cité plus haut. Voyons comment cela se présente pour l'encodage BASE64 :

Imaginons une classe css dans un projet Web dotnet (dans Visual Studio), qui permet d'afficher une image via une propriété "background". Avec l'extension Web Essentials installée, vous verrez apparaître dans la popUp de notification sur la ligne de votre propriété css 'background' le message :
Performance : the image is only 22(le poids de notre image) bytes and should be embedded as a base64 dataURI to reduce the number of http request.




Tout est dit dans ce message : le point important reste que cette option vous est proposée car votre image a un poids léger. Vous l'aurez, compris l'encodage en base64 n'est pas forcément adapté dans toutes les situations. D'ailleurs, ce type d'encodage entraîne en générale une augmentation du poids de l'image au moment du rendu.

Au passage, Web Essentials vous propose une optimisation de l'image en réduisant son poids (cf image ci-dessous).




Une fois l'option "Embed as base64 dataUri" sélectionnée, votre ligne css sera remplacée automatiquement par l'uri encodée.



Pour information
- L'encodage en base64 n'est pas supporté par les version IE antérieure à la 8.
- Cette technique d'encodage n'est pas seulement utilisée pour les images, mais peut servir pour d'autres types de ressource.
- il existe des encodeurs base64 en ligne


mercredi 30 septembre 2015

Un site web ASP.NET MVC 5 de A à Z - kick off avec Visual Studio

Hello à tous.
J'étais un peu absent sur mon blog ces derniers pour des raisons persos, but i'm back now :). Sans trop tarder nous allons nous plonger dans notre projet de faire un site web en ASP .NET MVC 5 et nous jeter à l'eau notamment avec l’initialisation du projet sous Visual Studio. A l'heure où j'écris cet article, on est à la version 2015, mais la version 2013 ferait aussi l'affaire. A noté également qu'avec Visual Studio 2015 nous avons la possibilité de créer un projet ASP.NET MVC 6 (VNext ou ASP .NET 5), version qui est bien avancée mais pas encore en release.

Page d'installation : https://www.visualstudio.com/ 

Pourquoi Visual Studio ?
Visual Studio est l'IDE par excellence pour faire du .NET. De plus, il faut reconnaitre que c'est l'un des meilleurs IDE (le meilleur pour moi) au monde et qu'il donne une aisance absolu en terme de développement : debugage, coloration syntaxique, outils de test, gestion de code source, etc

On démarre 
Une fois notre IDE favoris installé et lancé, on va en haut à gauche de notre IDE sur :
File => new => Project


On choisit ici à gauche dans la section des templates Visual C#, et on sélectionne "ASP.NET Web Application". Dans le bas de cette popUp, nous allons renseigner le nom de notre projet et solution : il faudra veiller à bien les nommer (le plus explicite possible) car cela facilitera la maintenance du code plus tard.


Ici, je vais considéré que Monsieur X (le commanditaire du site) a pour projet de nommer son site de vente en ligne "BuyMore". N'ayant pas plus d'infos pour l'instant, je vais nommer ma solution "ByMore", et suffixer tous les projets de ma solution ainsi. Au passage je coche les cases "Create directory for solution" (nous verrons ce que ça engendre au niveau des dossiers physique), et "Add to source control" afin de mettre en place une politique de gestion de code source dès le début du projet car il es important de pouvoir gérer son code source (faire des retours arrières par exemple).

Dans l'écran suivant nous allons sélectionner le template "MVC" et cocher la case "Add unit tests" afin d'instancier également un projet de tests unitaires dès le départ car il est également très important d'avoir des tests unitaires (automatisés si possible) pour notre projet et nous allons voir pourquoi plus tard.


Une fois que vous cliquez sur "OK", l'IDE vous crée l'arborescence de la solution physiquement.
Ayant au préalable cocher la case d'ajout au contrôle de code source, une popUp nous demande quel contrôleur de code source choisir :


Dans notre cas, nous allons utiliser "Git" (il est gratuit, contrairement à TFS). Une fois validé, notre solution apparaît enfin avec à l'intérieur notre projet "WebSite" et le projet de test associé :


Le petit signe + devant les objets de notre solutions indique l'ajout au contrôleur de code source (Git). Au niveau de notre répertoire physique, nous retrouvons également pour chaque projet un dossier conteneur associé, avec à la racine le fichier de solution (avec l'extension .sln) et des fichiers et dossiers de contrôle de code source Git.


On peut également constaté la présence d'un dossier "Packages" qui contient toutes les librairies annexes en prérequis pour un site web ASP.NET MVC 5, et qui contiendra les packages dont nous aurons besoin par la suite (les packages Nugget).

En exécutant (touche F5) notre projet Web, nous constatons que nous avons déjà un site fonctionnel avec plusieurs pages par défaut.



Conclusion
Avec Visual Studio, en moins de 5mn, nous avons initier un projet ASP.NET MVC 5 déjà opérationnel grâce au template MVC disponible. Nous avons également pu initié la prise en charge par un contrôle de code source (Git) que nous étudierons en détails dans les articles à venir, et nous avons intégré également un projet de tests unitaires. Nous verrons un peu plus en détails les éléments abordés ici dans mon prochain article.