Un process peut avoir plusieurs thread qui partage les mêmes espaces d’adressage gloables et les mêmes espace d’adressage avec d’autres threads qui tournent sur ce même process. Ils peuvent donc intéragir sur les mêmes adressage de données en même temps. Les processes ne partagent pas les mêmes espaces d’adressage et un mécanisme différent doit être utilisé si ils doivent partager les mêmes données. Un thread ne partage pas sa pile d’éxécution.

Si l’on considère une application “word” c’elle-ci est un process, le auto-save et autres features qui tournent en background sont elles des threads de ce process qui opère tous sur les mêmes données (le document).

1. Le process à son propre espace mémoire d’adressage. Les threads eux partagent le même espace mémoire d’adressage du process qui les a créés.

2. Un Thread a un accès direct à son segment de données de son process. Le process lui à sa propre copie du segment de données de son process parent.

3. Les threads peuvent communiques entre eux pour un même process. Les process doivent utiliser une communication interprocess afin de communique avec les process de sa famille.

4. Un thread est léger (pas d’overhead), un process est lourd (énormément d’overhead).

5. Des nouveaux threads sont faciles à créer, des nouveaus process ont besoin de la duplication d’un process parent.

6. Les threads peuvent exercer un contrôle quasi total sur d’autres thread du même process. Un process ne peut exercer son contrôle que sur ces process enfants.

7. Des changements sur le thread principal (priorité, annulation) peut affecter le comportement des autres threads de ce process. Un changement sur un process ne cause pas de changement sur ses process fils.
Qu’est ce qu’un service windows et en quoi son temps de vie diffère d’un exécutable (EXE) ?

Un service est démarrer avant que vous vous loggiez sur un système tandis qu’un exécutable a besoin que vous soyez logger pour fonctionner. Une service windows n’a pas d’interface d’utilisation, un exécutabel en possède générallement un. Les services windows sont générallement utilisés par des serveurs pour des applications qui ont une longue durée de vie.

Quel est la valeur  maximal d’espace mémoire qu’un simple process sur Windows peut adresser et en quoi est-ce différent de la valeur maximal de mémoire virtuel pour le système ?

Les process accèdent à des espaces mémoires virtuels, pas physiques. Les applications n’accèdent jamais à la RAM directement, elles utilisent l’inteface de gestion de mémoire du processeur.

Les valeurs d’adressage mémoire maximales dépendent des versions de windows utilisées et comment le programme a été compilé.

Tous les process 32bit sur Windows 32bit ont 4 gigas d’espace mémoire d’adressage. Les 2 gigas du dessus sont commun à tous les process et sont utilisés par le système. Les 2gb du dessous sont privée à chaque process et son inacesseble à tous les autres. A moins que le programme soit compilé pour utilisées un large espace mémoire, sa partie privée s’élève alors à 3gb.

Pour les processeurs 32bit sur Windows 64, chaque process à 2gb d’espace mémoire privé et 4gb si il est compilé en vue d’un large espase mémoire.

Pour les processeurs 64bits sur Windows 64, chaque process à 8TB d’espace mémoire privé si compilé pour utilisé un large espace mémoire. Les autres utilisent 2GB d’espace mémoire.

Ceci est complètement indépendant du nombre de RAM sur le système ou du Pagefile. Le system fait le lien entre l’espace mémoire physique et l’espace mémoire virtuel selon la disponibilité et ses besoins.

A chaque instant les données des l’espaces de mémoire virtuel pourrait être stoquée sur la RAM, sur le disque ou les deux. Tout ceci est totalement transparent à toutes applications. Les données souvent accédées seront stoquées dans la RAM, les autres sur le disque.

Quel est la différence entre un exe et une dll ?

Un exe est un programme exécutabel. Une dll peut être loader et utiliser par un programme dynamiquement. De manière simple c’est un répertoire de code pour des programmes. Plusieurs programmes vont utiliser les mêmes dll à la place d’avoir ce code dans leurs propres ficiers, cela permet de diminuer l’espace mémoire. Un synonyme est libraire de classe.

Un dll n’a pas de fonction principal, un ex en a un.

Une Dll est inprocess, composants et consomateurs de la dll partageront le mêmes espace mémoire. Un exe est outprocess, il fonctionnera avec son propre espace mémoire.

Auel est la différence type entre fortement lié (strongly typing) et type faiblement lié (weak-typing), lequel préférer et pourquoi ?

Le typage fort est préféré car il ne laisse pas la place à un typage ambigu ou incorrect. Les erreurs sur les typages fort seront intercepté à la compilation tandis que le typage faible sera intercepté lors de l’exécution (ce que vous ne voulez généralement pas). Par exemple un Array d’objet et un typage faible car il permet de lui ajouter un string ou int. Il y a un risque lors de l’éxécution que vous parcourez votre Array et que vous recevez un type qui vous n’aviez pas prévu.  Une List<string> est un objet à typage fort car il ne permet de jouer qu’avec une liste de string et rien d’autre. MaListString.Add(5) sera reconnu à la compilation, tandis que le monArray.add(”unstring”), si ce string ce trouve à la première possition de votre array et que vous écrivez, int unchiffre = Convert.ToInt32(array[0]); vous n’aurrez une erreur qu’à l’éxécution.

Quel sont les components qui sont délivrés avec Windows Server Family ?

System.WEB.UI.Page, Syste.Windows.Forms.Fom, System.ComponentModel.Container. L’essence du développement est de ne pas développer un composant qui existe déjà sur le marché pour peu d’argent et même parfois gratuitement. Il vaut générallement mieux utiliser un composant tier, testé plutôt que d’en créer un en entier. Presque toutes les classes de .NET sont des composants, ils peuvent être réutilisés, ils sont sous version et ils peuvent être compilé dans une dll. Une définition plus stricte d’un composant serait en gros, une “surface” dans laquelle vous déposeriez une instance d’un objet dans Visual Studio .NET, vous pourriez alors lui définir ses propriétés et des gestionnaires d’évênements sur ceux-ci visuellement. Ils sont des “designable component”, ceux-ci devront absolument implémenter l’interface IComponent. Ces objets de “design” n’ont pas forcément besoin d’une surface, les classes qui dériveront de System.Web.UI.Page et System.Windows.Forms.Form seront aussi bien des contrôlles que des composants. L’existence de component impute l’existence de conteneur. En .NET, ASP.NET Webforms et Windows Forms sont des composants conteneur visuel. Les conteneurs jouent un rôle important dans la gestion des components. En particulier tout conteneur implémente la méthode IDisposable, ce qui veut dire qu’ils ont la méthode dispose permettant de déliverer les ressources comme un fichier ouvert un gestionnaire d’évênement. Dans leurs méthodes dispose, ils devront appelers les méthodes Dispose de tous leurs compontents.

La suite un autre jour…

Après un ècran bleu et en redèmarrant mon ordi et ensuite ma solution, je recevais l’erreur suivante :

Could not load file or assembly ‘Aspose.Pdf’ or one of its dependencies. The parameter is incorrect. (Exception from HRESULT: 0×80070057 (E_INVALIDARG))

Manifestement un problème de cache vu que la solution n’avait pas changè. Si comme moi vous roulez sur Windows 7 sur un utilisateur normal mais avec visual studio qui tourne en administrateur, alors vous devrez supprimer tout ce qui se trouve dans le rèpertoire suivant :

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files

Relancez votre solution et normalement l’erreur devrait partir.

J’espère que cela vous aidera…

ASP.NET MVC2 - Introduction

ASP.NET MVC2 - Votre première application

ASP.NET MVC2 - Le modèle et la vue fortement liée

Le modèle :

Pour expliquer la notion de modèle, je reprendrai l’exemple de Mr Steven Sanderson.

Voici le contexte :

Votre amis organise une soirée et voudrait que vous créiez un site qui permette aux invités de répondre via l’intermédiaire d’un formulaire envoyant un message électronique.

Cette application devra :

Afficher les informations concernant la soirée par une page Index.
Posséder un formulaire où l’invité peut entrer ses coordonnées et prévenir si il s’y rend ou pas.
Envoyer un email détaillé de ces invitations à l’organisateur.

Reprenons noter page créée précédemment (voir ASP.NET MVC2 - Votre première application) dans la vue index et rajoutons-y quelques informations :

Voici le résultat :

Voici donc notre vue incluant un lien, si nous cliquons sur celui-ci, nous recevons une erreur 404. Ceci est tout à fait normal vu que nous n’avons pas d’action portant ce nom dans ce controller.

Vous remarquez que contrairement à l’ASP.NET classique, le lien ne correspond pas à un fichier se trouvant sur le serveur mais à une configuration de votre sytème de routing . Celui-ci vous aidera à vous diriger vers une action comprise dans un controller.

Chaque action aura automatiquement sa propre URL. Vous n’avez donc pas besoin de créer une page ou une classe pour chaque lien.

En faisant un view source du code générer par la méthode action link, vous voyez que le résultat est un html propre :

<a href=”/Home/SEND”>Inscris-toi maintenant</a>

En effet, ActionLink est l’un des composants permettant la génération d’HTML à partir de la class « helper » html compris dans le framework ASP.NET MVC. C’est dans cette classe que vous trouverez les méthodes pour générer vos textbox, textarea, checkbox,…

NB : Vous remarquerez que la méthode ActionLink est surchargée et permet donc des comportements différents, je vous laisse découvrir cela par vous-même.

Nous verrons également que nous ne sommes pas obligé d’utiliser ces méthodes et que nous pourrions tout aussi bien utiliser du html écrit “à la main”. Afin d’avoir un apperçu des différents composants, je vous invite à explorer celui-ci via l’intellisense de Visual Studio. J’ai le présentement que vous allez vous servir de ce helper assez souvent dans les prochains mois.

Créons maintenant une action SEND dans notre controller et ajoutons-lui une vue.

Ajoutez cette vue SEND de la même manière que dans notre dernière article, Bouton-droit ajouter une vue.

Lancez l’application et regarder si la page blanche créée s’affiche correctement.

À ce stade, vous seriez tenté de continuer comme dans une application ASP.NET classique et créer un formulaire dans cette page via des contrôles ASP.NET.

C’est ce que nous allons faire mais avant cela attardons nous sur notre modèle.

En effet, le modèle est l’une des parties les plus importantes de notre application. En effet, si on y réfléchit, c’est celui-ci qui renfermera la connaissance que nous avons sur notre domaine. Le reste n’étant que des outils facilitant l’affichage et/ou à la manipulation de données. C’est dans notre modèle que la logique de notre situation transparaîtra. C’est lui qui doit refléter le monde réel, il est entièrement créé par vous et peut donc correspondre de manière très proche à la réalité. que vous vous êtes faites de votre domaine

Dans notre cas, notre domaine n’est pas très compliqué, ce qui aura pour effet la création d’un modèle simple.

Un simple objet encapsulant les coordonnées et un paramètre nous permettant de savoir si la personne assistera ou non à la soirée sera un modèle valable pour cette application.

Ajoutez un fichier ReponseVisiteur.cs dans notre modèle et ajoutez à cette classe les paramètres souhaités.

Seul particularité de cette classe, le paramètre WillAttend est de type booléen nullable part l’ajout du caractère ‘?’ directement après la déclaration du type de la variable. Ce qui paramétra la création d’une variable à trois états, true, false ou null.

Créons maintenant le formulaire pour la vue.

Si vous lancez cette application, vous remarquerez que lorsque vous cliquez sur le bouton submit, la page se recharge en perdant les informations entrées dans le formulaire. Ce comportement est tout à fait normal. En effet, l’action SEND a pris en charge votre requête car vous n’avez pas d’autre action dans votre controller capable d’interpréter un post de manière correcte.

Nous remarquons que ce comportement n’est pas tout à fait normal, en effet, l’action SEND de votre controller ne devrait être utilisé que pour une méthode de type GET, c’est-à-dire seulement pour afficher la vue et non pas pour interpréter une requête de type post.
Pour cela, ajoutons un attribut permettant à l’action de n’accepter que des requêtes de type GET. Faisons de même pour la méthode index de notre HomeController.

Relançons notre application et regardons ce qu’il se passe. Après avoir appuyé sur notre bouton submit. Nous recevons une page d’erreur 404.

Comportement normal, il n’y a maintenant plus d’action dans notre Controller capable de répondre à une requête de type “post” à l’url correspondante (Home/SEND).

Nous devons donc créer une nouvelle méthode afin de pourvoir interpréter cette requête. Celle-ci ne devra prendre en compte que des requêtes de type POST, elle devra prendre en paramètre un objet de type ReponseVisiteur (créé depuis notre formulaire de la page SEND) et à partir de ce même objet, devra exécuter de la logique et ensuite être retournée, par exemple, à une vue Thanks. Cette vue devra afficher un message différent suivant la réponse de l’invité.

Le Model Binding :

Grâce au Model Binding (composant d’ASP.NET MVC), les données entrantes sont automatiquement créées et utilisées en paramètre par les actions, ceci étant possible par une correspondance de paires clé/valeur entrantes avec le nom de la propriété du type désiré en NET.

Plus concrètement, ce binding, nous permettra d’éviter de devoir jouer avec des dictionnaires tels que Request.Form[] et Request.QueryString[]  aussi souvent qu’en webforms. En effet, comme les noms de nos contrôles se trouvant dans la page SEND.ASPX correspondent aux noms des propriétés de nos objets. Automatiquement, le framework nous fournira une instance de notre objet ResponseVisiteur avec n’importe quelle valeur entrée dans nos contrôles.

Revenons à nos moutons et retournons à nos deux actions afin d’illustrer ce comportement :

Nous remarquons qu’il est donc possible de passer un objet à une vue.
À noter que pour arriver à ce résultat, nous devons ajouter le namespace « using Kiwi.Web.Models » afin d’avoir un accès à nos modèles.

Vue fortement typée :

Si vous regardez attentivement l’action SEND devant interprétée une requête de type POST, nous passons à la vue “Thanks” un objet de type ReponseVisiteur. Pour que cette vue puisse interpréter cette objet, il faudra donc créer une vue dite fortement typée. En faisant cela, nous définissons le modèle de la vue. Nous pourrons alors depuis celle-ci accéder aux propriétés de cette objet.

Créez cette vue fortement typée. Pour cela, cliquez-droit sur le nom de votre action > add > View.

Nous arrivons sur cet écran :

Nous définissons donc le type ReponseVisiteur comme mode pour notre vue. Cliquez sur Add et une vue Thanks sera ajoutée à notre site.

Voici notre vue :

La partie soulignée en rouge est importante, en effet, nous voyons que notre vue héritée de la classe MVC.Viewpage est typée fortement par ResponseVisiteur.

Le point fort de ce typage est l’accessibilité aux paramètres de l’objet depuis notre vue.

Comme vous le remarquez, nous avons accès au propriété de la classe par Intellisense.

Essayons de nouveau d’envoyer notre formulaire en introduisant quelques valeurs (attention pas de validation pour le moment).

Voilà le résultat.

Premier constat : html propre, pas de viewstate. N’est ce pas génial ?

Ajoutons maintenant de la Validation :

N’oublions pas que cette validation concerne le modèle et non pas la vue. En effet, les validations reflètent généralement des règles du business. Et il sera, pour vous, plus facile de maintenir vos règles si celle-ci se trouvent à un seul et même endroit dans votre application. Autre avantage, en intégrant les règles dans votre modèle, vous êtes certains que l’intégrité de votre système reste respecté et ce quelque soit la vue ou le Controller qui est connecté avec ce modèle. Ceci est, selon moi, une manière plus robuste que les contrôles de validation d’ASP.NET de type <asp:XyzValidation>.

La manière de valider qui va suivre n’est pas la plus puissante et nous verrons plus tard les autres techniques de validation qui existent en ASP.NET MVC.

Pour cela, rendez-vous dans votre objet ReponseVisiteur et implémentez l’interface IDataErrorInfo.

Maintenant, retournons dans notre controller afin d’adapter notre action suivant le résultat de la validation.

Et pour la vue, nous rajoutons la méthode Helper HTML.ValidationSummary(), cette méthode permet d’afficher les messages d’erreurs contenu dans notre Modèle.

Grâce au binding du modèle qui « parse » les données entrantes, nous pouvons retournée la vue et si nous rencontrons une erreur, les contrôles seront réinitialisés avec les données qui avaient été introduites auparavant. Pourtant, nous sommes dans un contexte http « stateless ». Cela crée une apparence d’application « statfull », nous verrons ces mécanismes plus en profondeur plus tard.

Réessayons notre application :

Terminons l’application en rajoutant notre méthode permettant d’envoyer un mail :

Cette application utilise l’API SMTPCLient. Par défaut, SMTPClient cherche les paramètres concernant le serveur mail dans le Webconfig de votre site. Ajoutez ces lignes pour envoyer des mails :

Généralement, en développement, on préfère stocker les mails dans un répertoire plutôt que de polluer le destinataire, pour cela configurez votre webconfig de la manière suivante :

Je vous laisse le soin de configurer ceci et de tester cette application.

En conclusion :

Vous venez de créer une première vraie application ASP.NET MVC, vous avez maintenant appris à jongler avec les vues, le controller et le modèle. Vous savez maintenant lier une vue avec un modèle et vous avez également approché le concept de validation dans ASP.NET MVC.

Pour terminer regardons de plus prêt l’architecture ASP.NET MVC :

Dans cette architecture, les requêtes HTML de type request sont routées vers un controller, celui-ci travaille avec le modèle afin d’interpréter les données utilisateurs et mener à bien la requête. Le modèle représentant la logique du business et le Controller la logique de l’application (gestion de la session, authentification,…). Lorsqu’il faut retourner les données vers l’utilisateur, le controller prépare ces données pour la vue par l’entremise du « presentation model », le ViewData en ASP.NET MVC.

Le Controller n’étant pas lié à la vue, celui-ci est entièrement testable. Les vues, elles, sont de simples outils permettant d’afficher du HTML à partir de données se trouvant dans le viewdata. Elles permettent l’itération afin de générer des tableaux, des listes, elles ont la possibilité de cacher ou non une partie de page et bien d’autres comportements sont possibles. De manière générale, cette logique doit rester simple et ne peut avoir comme but que l’affichages de données et de formulaire. Vous ne penserez plus en terme de contrôle comme en ASP.NET classique mais en terme de requête request/response HTML.

Pour plus d’info concernant les différentes architectures du point de vue théorique, je vous renvoie vers le site de Mr Fowler : http://martinfowler.com/eaaDev/uiArchs.html

Au point de vue .NET :

Les controllers sont des classes ASP.NET MVC qui dérivent toutes de la classe Controller d’ASP.NET MVC. Chaque classe publique appelée « Action method » est automatiquement associée à une URL se trouvant dans le schéma d’URL que vous configurez. Ces actions exécutent les opérations et renvoient ensuite une réponse, par exemple, l’affichage d’une vue. Ce mécanisme d’entrée/sortie a été pensé dans le but d’être testable facilement, vous n’êtes donc pas couplé à un serveur Web en fonction.

Le framework supporte différent view engine. Par défaut, les vues sont de simple page webforms aspx,libérées du viewstate, du code-behind (pas de .cs) et du comportement des postbacks.

Concernant votre modèle, ASP.NET ne vous fournit pas de cannevas et vous êtes libre de créer vos objets dans la manière qui vous sierra le mieux. Concernant les aller/retour entre modèle et base de données, vous êtes encore une fois libre d’utiliser vos propres classes ou n’importe quel ORM fonctionnant en .NET. Par défaut, ASP.NET MVC créé un répertoire Model, vous pouvez l’utilisez mais libre à vous de créer une dll et d’utiliser celle-ci en modèle.

Vous remarquerez qu’ASP.NET MVC n’est pas tout à fait un MVC classique mais adapté au web et à l’ASP.NET.

Je pense que vous êtes maintenant prêt à passer dans le vif du sujet et construire une application réelle en utilisant ASP.NET MVC. J’espère vous avoir donné une bonne introduction via ces trois premiers articles. Dans mes prochains articles, nous approfondirons certains composants d’ASP.NET MVC et j’espère que nous arriverons à construire cette application ensemble dans une philosophie agile. J’attends de vous un retour afin de discuter des choix architecturaux au cours de ce périple. À bientôt !

ASP.NET MVC2 - Introduction

ASP.NET MVC2 - Votre première application

ASP.NET MVC2 - Le modèle et la vue fortement liée

Pré-requis :

Pour pouvoir utiliser ASP.NET MVC2, vous devez au moins utiliser les systèmes d’exploitation suivants :

- Window Xp, Vista, 7, server 2003, server 2008.

Pour ce qui est de l’IDE :

- Visual studio 2008 (avec SP1) peu importe l’édition, Visual Studio 2010 (peu importe l’édition), Visual Web Developper 2008 Express (attention, avec cette version, vous n’aurez pas accès aux projets de test unitaire compris dans Visual Studio 2008).

Attention : Il n’est pas possible de construire des applications ASP.NET MVC avec Visual Studio 2005.

Si vous n’avez jamais installé de framework ASP.NET MVC sur votre machine, il suffit simplement de le télécharger ici : http://www.asp.net/mvc/.

NB : Par contre si vous utilisez comme moi Visual Studio 2010 RC1, la version fournie est ASP.NET MVC 2 RC1, pour installer la dernière version c’est à dire ASP.NET MVC 2, vous devez tout d’abord désinstaller la version ASP.NET MVC 2 installée sur votre système et ensuite installer la dernière version téléchargée. Source de mon information : http://haacked.com/archive/2010/02/10/installing-asp-net-mvc-2-rc-2-on-visual-studio.aspx

Pour ma part, ma configuration dans cette série sera Visual Studio 2010 CTP avec la dernière version d’ASP.NET MVC 2 RTM.
Concernant la base de données, j’utiliserai Sql Server 2008 Express edition que vous pouvez télécharger via ce lien : http://www.microsoft.com/express/database/.

Maintenant que vous êtes en possession de tous les outils requis, je vous invite donc à créer une première application MVC.
Pour cela, File > New > Project

Cliquez sur ok, nous avons alors une boîte de dialogue qui apparaît afin de savoir si nous voulons y accoler un projet de test.

Nous cliquerons sur « No, do not create a unit test project ». Nous reviendrons sur cette partie plus tard.

Vous voilà en face d’une nouvelle application MVC. Si vous naviguez dans le solution explorer de ce projet, vous remarquerez qu’il n’est pas vide.

Pressez CTRL+F5 afin de lancer l’application.

Si vous arrivez à cet écran, c’est que tout se passe bien et que votre installation s’est bien déroulée. En cas de problème, n’hésitez-pas à laisser un commentaire, je me ferai un plaisir de vous aider.

Fermez votre navigateur et assurez-vous que le débuggeur soit bien stoppé.

Retournons dans le “solution explorer” et supprimons les fichiers qui ne nous intéressent pas. En effet, ASP.NET MVC crée pour nous une application prête à l’emploi.

Nous aurions pu, au lieu de créer une ASP.NET MVC2 application, prendre le template vide que nous fournit Visual Studio mais je voulais m’assurer du bon fonctionnement de votre configuration.

Nettoyez les fichiers tels que montrez dans l’image ci-dessous :

Rendez-vous dans le Controller HomeController. Il sera votre controller par défaut, si je puis dire, et nous verrons plus tard pourquoi. Supprimer les classes construites à l’intérieur de celui-ci et créez une méthode qui renvoie un string.

Lancez l’application et vous devriez avoir le résultat suivant :

Wow, vous venez de créer votre première application ASP.NET MVC ! Félicitation, ce fût dur n’est-ce pas ?

Trêve de plaisanterie, que s’est t’il passé lors du lancement d’application :

Nous avons lancé l’application, celle-ci à envoyé une requête http de type GET, cette requête a, apparemment, été interceptée par notre HomeController etla méthode que nous avons écrite a été exécutée.

À l’aide de l’outil FireBug de Firefox, analysons les requêtes http, voici ce que nous dit FireBug concernant la requête envoyée :

Et voici ce que nous avons eu en retour :

Un string « Welcome to a my First MVC Application ». Vous noterez au passage la faute de frappe, j’aurais dû écrire « Welcome to my First MVC Application », je vous laisse corriger cette erreur.

Maintenant, regardons le code source de cette page, nous voyons que ce n’est pas du html mais un simple string renvoyé par le controller. Suis-je donc entièrement maître de ce que j’envoie comme réponse au client ? La réponse est oui.

En MVC, le controller est responsable d’intercepter les requêtes rentrantes. Dans ASP.NET MVC, le controller est une simple classe C# qui dérive de System.Web.MVC.Controller. Chaque méthode “public” d’un controller est appelé une action. Cette action pourra être atteindre par le web via l’URL.

Récapitulons, vous avez un controller HomeController et une méthode d’action Index. Comment l’application fait-elle le lien entre cette action et votre url. En effet, lorsque vous lancez l’application, l’url est « / ». En fait, Si vous vous rendez dans le global.asax, vous verrez ceci :

En fait, au commencement de l’application (Application_Start()), l’application charge toutes routes définies dans la méthode RegisterRoutes().

Dans celle-ci nous avons une route par défaut.

Si nous regardons cette route pas « Default », en dernier lieu, un objet anonyme qui donne en paramètre, le controller Home, l’action Index et un string vide en id. C’est cette ligne qui crée notre route par défaut.

L’action Index compris dans le controller Home sera donc exécuté lorsque l’url aura les valeurs suivantes :
/
/Home/
/Home/Index

L’action Index étant l’action par défaut lorsque rien n’est renseigné après le nom du Controller dans l’url.

Par défaut également, si vous créez un controller nommer ProductControlller, automatiquement, sa route sera /Product et non /ProductController. Nous parlerons plus en détails de ce comportement au moment opportun.

Renvoyer de simples string n’étant pas très utile, nous allons maintenant tenter d’envoyer du beau html.

Créer et afficher une vue :

Pour cela retournons dans notre solution explorer et supprimons le fichier Index et About qui se trouve sous le répertoire Home.

Ensuite retournons dans notre controller et modifions l’action Index comme ci-dessous :

Action result est une classe abstraite, vous ne pourrez donc par retourner un new ActionResult. Vous devrez retourner un type qui dérive d’ActionResult, nous utilisons la méthode View qui retourne un ViewResult. Il existe plusieurs classes dérivant d’ActionResult, nous verrons cela prochainement.

Que fait cette méthode View() ? On sait qu’elle retourne un ViewResult mais ou va-t-il chercher sa vue ? Pour le savoir et à condition que vous ayez bien supprimé les fichiers About et Index en dessous de répertoire Home. Vous devriez avoir le comportement suivant :

En effet, il ne trouve aucune vue se nommant Index dans le répertoire HOME de votre solution. Ce qui est normal, nous les avons supprimés.
Les vues sont associées avec une action par une convention. Lorsque le framework veut trouver une vue par défaut pour l’action index du controller HomeController, vous voyez sur l’image ci-dessus les endroits dans lesquelles le Framework cherche cette fameuse vue.

Pour créer une vue depuis votre controller, faites bouton-droit sur le nom de l’action, comme ci-dessous :

Vous avez alors la boîte de dialogue suivante :

Vous voyez que par défaut le nom de votre vue est Index, si vous changez celui-ci et laissez la méthode View() telle quelle, cette vue ne sera par trouvée. Elle ne respectera pas la convention utilisée par le framework. Vous devrez alors fournir des paramètres à la méthode View(), ce que nous verrons plus tard.

Vous remarquez également que ce dialogue nous permet de choisir si nous voulons utiliser une master page ou pas. Nous allons utiliser la master page par défaut et ajouter cette vue à notre application en appuyant sur le bouton Add.

Une page aspx s’ouvre alors, vous pouvez maintenant la remplir de HTML comme bon vous semble.

Un exemple :

CTRL+F5 pour lancer l’application et voici le résultat :

En premier lieu, on voit bien que le MasterPage a été chargé. Ce qui est normal vu que l’attribut MasterPageFile de notre Page renseigne bien notre MasterPage.

Analysons maintenant la réponse qui a été envoyée à notre client par la suite de notre méthode GET.

En réponse nous voyons bien, que la réponse est maintenant une page html et non plus un simple string :

Vous pourriez tout aussi bien retirer le lien vers le masterpage en supprimant en entier l’attribut MasterPageFile= « votre lient ». Attention dans ce cas, vous devez supprimer toutes les balises <asp :content> et  recréer une page html en entier avec son head, son body,…
Voici notre nouvelle vue sans master page :

Et le résultat :

Le mécanisme des masterpages n’est pas une nouveauté en ASP.NET MVC mais on voit qu’il continue à fonctionner. À noter que le masterpage n’a pas de code-behind. Il est juste ce qu’il doit être, un squelette pour notre application. Nous y reviendrons plus tard et nous allons réutilisez cette vue (maintenant sans masterpage) afin d’afficher un contenu dynamique.

Modifions l’action comme tel :

Et notre vue de la manière suivante :

Et vous obtenez le résultat suivant :

Que s’est-il passé lors cette exécution ?

Le navigateur a envoyé une requête GET afin d’atteindre l’action lié à l’url « / », par l’entremise des Routes, cette méthode est envoyée vers l’action Index de l’objet HomeController. Cette index est interprété et retourne sa vue par défaut. Cette action Index passe des données à sa vue par l’intermédiaire de l’objet ViewData. Ces données sont interprétées par la vue à l’aide de la commande en ligne <%=ViewData["message"] %>. Cette vue maintenant interprétée est renvoyée au client par l’intermédiaire d’une requête HTTP de type réponse. Pour finir, votre navigateur affiche le résultat de cette requête.

Cette explication ne rentre bien évidemment pas, pour le moment, dans les détails. Nous nous y attarderons plus en profondeur bientôt.

En conclusion :

Vous venez donc de créer votre première application ASP.NET MVC2 ! Vous avez ajouté un peu de logique à votre action afin rendre le tout plus dynamique. Vous avez remarqué lors de cet exercice que l’objet ViewData permet de passer des valeurs à la vue et que grâce au commande en ligne d’ASP.NET et ces célèbres balises <% %>, vous avez affiché dans votre vue, des données se trouvant dans votre controller.

Avant ce dernier exercice, vous avez appris la notion de vue et celle de Controller, vous avez approché la notion des routes et la notion de requête http qui transite depuis votre navigateur jusqu’au server Web et vice-versa.

Nous arrivons donc à la fin de cette article, vous aurez certainement remarquez que nous n’avons pas parlé du M de MVC, le modèle. Nous approcherons ce principe plus en détail dans notre prochain article. Dans celui-ci nous verrons comment communiquer avec le Modèle par l’intermédiaire du controller. Nous terminerons alors avec une partie théorique avant de passer aux choses sérieuses. Le développement d’une application réelle.

Introduction :

J’ai décidé de créer une petite série afin de vous montrer les nouveautés ASP.NET MVC2. De nombreux blogs fleurissent sur ASP.NET MVC ces temps-ci, principalement en anglais et il me semblait que la qualité d’information en langue française manquait quelque peu. J’aurais pu continuer mon blog en anglais comme j’avais d’ailleurs débuté à le faire il y a quelques temps. Néanmoins, après avoir discuté avec certains collèges et amis, j’en suis venu à la conclusion qu’il était peut-être plus utile que je m’exprime dans ma langue maternelle. J’aurai, en effet, plus de facilité à vous expliquer les différents aspects de MVC2.

Nous sommes le 15 Mars 2010 et hier, ASP.NET MVC2 a été délivré et oui, bonne nouvelle, nous pouvons enfin l’utiliser en production. Dans cette série, je créerai un CMS, oui réinventer la roue, mais ce concept compris de tous sera donc plus facile pour vous d’assimiler les nouveautés que nous apportent ASP.NET MVC.

Qu’en est-il de ASP.NET Webform ?

Rassurez-vous, ASP.NET MVC ne va pas remplacer les webforms, il est juste un autre type d’application que nous fournit Microsoft. Les améliorations pour les Webforms continueront. D’ailleurs, il y a pas mal de nouveauté très sympa avec le nouveau ASP.NET 4.0 (je pense au ClientMode ID, le routing, etc…).

Pourquoi donc apprendre ASP.NET MVC ?

Oui vous pourriez bien continuer à utiliser les webforms classique mais vous rateriez quelque chose. Je m’explique, si vous êtes développeur ASP.NET, vous êtes donc, que vous le vouliez ou non, un développeur Web. Votre client est bien un site web. Dans ce cas, je pense que vous devez tenir compte d’une certaine philosophie web. Par exemple, respecter les standards du web, utiliser du Javascript, avoir connaissance des requêtes html envoyées au serveur, utilisez du CSS pour créer votre design,…

Les webforms nous fournissent un outil utile mais il a été pensé de la même manière que les winform. En effet, ASP.NET fournit une couche d’abstraction de la couche ui. Vous pourriez donc bien écrire une application ASP.NET sans écrire le moindre code HTML. Cette couche d’abstraction est peut-être utile. En effet, pas besoin de savoir ce qui se passe derrière, plus besoin de connaître les requêtes http que nous recevons du client, ni celle que nous envoyons au client, tout se passe comme par magie. Nous n’avons plus qu’à mettre notre code dans le codebehind de notre page. Mais cette abstraction a un prix. En effet, tenter de fonctionner dans un esprit « statefull » (comme winform) dans un environnement qui est stateless (le web, client/serveur web) nous coûte quelques contraintes.

Pour commencer le viewstate, il est l’un des mécanismes qui nous permet de faire le lien entre l’orienté objet et le html. Il va, par exemple, détecter les changements intervenus à la page. (plus d’information sur le viewstate, ici : http://www.dotnetguru.org/articles/dossiers/viewstate/viewstate.htm). À chaque action, un postback sera exécuté et transférera l’entièreté du ViewState vers le serveur web. Il pourra atteindre quelques milliers de kylobytes et ainsi « alourdir » l’application. Utiliser l’Ajax par ce principe est aussi paradoxal, il n’est pas dans la philosophie ajax (optimiser les requêtes entre le client et serveur et ce, de manière asynchrone).

Un autre point qui permet la communication entre le client et le serveur est le « page life cycle ». Cette série d’événements clients, serveurs peut devenir très vite difficile à comprendre pour des applications complexes. Je suis certain que vous êtes un spécialiste du «page view cycle » mais, personnellement, j’ai déjà passé quelques heures à comprendre pourquoi un de mes «events handlers » ne s’étaient pas exécuté.

Déposer un gridview dans le designer et lui connecter un objectdatasource, rien de plus facile pour faire vite mais quel contrôle avons-nous sur le html généré? Ce html est parfois généré de manière douteuse et peu standard. Ne parlons pas des ID générés de parfois plus de 50 caractères qui ne seront pas facile à intercepter en utiliser javascript et encore moins pour le CSS.

Le code-behind de la page qui entraîne des applications fortement couplées entre la vue et la partie logique. En effet, il n’est pas rare d’avoir du code qui manipule des données depuis une base de données directement dans le load d’une page. Quelques patterns nous permettent de remédier à la situation mais ils sont, selon moi, non encouragés de part l’architecture des webforms. De plus, ASP.NET mène au mixte entre le code ASP compris directement dans la vue et nos objets se trouvant dans le code-behind de la page. Il en résulte un couplage fort entre vue et logique serveur. Cela nous donne des applications difficilement maintenables et fragiles à l’extension.

Un code difficilement testable. Avec l’émergence des méthodologies Agile, le pattern TDD devient peu à peu un standard dans le monde du développement. En effet, qui n’a jamais entendu parler de tests unitaires ou d’outils de mocking à l’heure d’aujourd’hui? Construire du code robuste et tester avant même sa mise en QA est devenu banal. Cette manière de faire nous est impossible (ou presque) en winforms. En effet, l’architecture n’a pas été pensée dans ce but.

Je suis certain qu’ASP.NET continuera à être amélioré au fur et à mesure des releases. Des progrès sont à noter avec le contrôle d’un HTML plus propre possible avec ASP.NET 4.0 mais son gros point faible restera toujours sa non-testabilité (pour le moment).

ASP.NET MVC, lui, plus nouveau, a été pensé dans une autre philosophie, celle des méthodologies Agile, du TDD, des IOC/Dependency Injection, du respect des standards web, du protocole REST,…

Microsoft a répondu à ses développeurs et à ses détracteurs en nous donnant le choix d’utiliser ASP.NET MVC.

Le succès connu ces derniers temps par Ruby on Rails (open source) ne doit pas être totalement anodin. En appliquant les dernières mouvances du développement web, une architecture MVC, en travaillant avec les requêtes http et non en les rendant abstraites et en intégrant un ORM en son cœur, Ruby on Rails est vite devenu une coqueluche auprès des développeurs web. Certains développeurs ASP.NET connus de la communauté comme Rob Connery se sont même converti vers cette technologie. Je vous conseille, d’ailleurs d’y jeter un œil.d Ruby on Rails est très intuitif et pour l’avoir essayé, c’est un framework agréable totalement dédié au web.

Les avantages du ASP.NET MVC :

Justement le MVC :

Le model-view-controller est un pattern connu depuis longtemps dans la communauté des développeurs orientés objets, il a été introduit en 1978 dans le projet SmallTalk et est maintenant très populaire dans le monde du développement web.

-Les interactions entre utilisateurs et serveurs prennent un cycle naturel. L’utilisateur émet une action, en réponse le serveur change sont modèle et retourne une vue mise à jour par l’utilisateur. Et le cycle se répète indéfiniment, très pratique pour les applications web qui ne sont finalement que des séries de requêtes http échangées entre client et serveur.

-Une application est un système complexe, il est la résultante de différentes technologies, en effet, en tant que développeur web .NET, vous devez maîtriser le HTML, le CSS, le javascript, l’ASP.NET, le C# (ou le VB.NET), des connaissances en orienté-objet et des connaissances en base de données. Une application en couche est donc la moindre des choses pour ce genre d’application et le pattern MVC se marie assez bien dans des architectures multicouches.

Un système extensible à souhait :

ASP.NET MVC a été bâti dans une philosophie Agile, il est extensible. En effet, l’ASP.NET MVC est un ensemble de composant mis à votre disposition pour répondre à vos envies de développeurs web. En utilisant interfaces et classes abstraites, le framework nous donne donc la possibilité de remplacer facilement les composants que nous voulons changer pour x ou y raisons. Vous allez donc pouvoir changer le routing system, le view engine, le controller factory et ainsi de suite. Cela tout simplement en implémentant les interfaces et les classes abstraites adéquates. De manière générale, ASP.NET MVC nous donne ces solutions :

-Utilisez le fonctionnement par défaut.

-Dériver une sous-classe de l’implémentation par défaut en vue de changer légèrement le comportement de celui-ci.

-Remplacer entièrement un composant avec une nouvelle implémentation des interfaces et des classes abstraites fournies. Un peu comme le Provider modèle fourni en ASP.NET 2.0.

Un système testable:

L’architecture MVC nous donne des applications qui seront facilement testables mais aussi facilement maintenables (par la séparation des différentes couches). De plus, il nous permet de facilement « mocker » chaque partie du framework. Nous verrons cela plus tard dans notre série.

Le contrôle du HTML généré:

En fait, c’est assez simple, vous êtes maintenant maître du HTML produit. Plus d’id mirobolant, plus de viewstate, vous pouvez maintenant produire du code hautement standard et donc plus facilement maintenable. De part cette aspect, vous pourrez maintenant très facilement reprendre le HTML fourni par votre intégrateur (si ce n’est vous-même) dans vos vues. Vous allez pouvoir construire votre design sans vous souciez qu’il soit écrit en ASP.NET, en PHP, en Ruby ou que sais-je. Par ce contrôle sur le HTML, vous pourrez donc très facilement y intégrer des plugins javascript. Microsoft ne s’y est d’ailleurs pas privé en vous fournisseurs dès le départ Jquery. Vous allez vois, l’essayer, c’est l’adopter.

Des URL propres:

De nos jours, les url propres sont devenues une demande classique dans les solutions web. Les searchengines donnent un poids conséquent aux mots clés compris dans les url, ce qui en fait un requis pour le recensement. Des urls propres donnent également la possibilité de naviguer directement depuis la barre d’adresse de votre navigateur. De même, ils entraînent plus de confiance envers votre site. La peur de partager des liens sans donnée personnelle deviendra inexistante. ASP.NET MVC, nous fournit un composant puissant et malléable afin de mettre en place ce système de liens propres. La classe system.web.routing, vous aurez un contrôle total de vos liens, il sera donc aisé de coller au protocole REST.

La puissance du framework .NET:

ASP.NET MVC vous donne les mêmes droits sur le framework que l’ASP.NET. Aucune restriction concernant son utilisation. De plus, vos anciens contrôles développés en webform pourront continuer à coexister avec ASP.NET MVC. Le déploiement d’ASP.NET MVC se fera peu ou prou de la même manière qu’une application ASP.NET classique, il vous faudra juste installer la bonne version d’ASP.NET MVC sur votre serveur.

Open source :

Vous voulez aller plus loin et comprendre comment a été conçu le Framework ? Rien ne vous empêche de prendre le code source d’ASP.NET MVC et de référencer celui-ci dans votre solution. Vous êtes alors prêt à explorer les moindres recoins du Framework. En effet, ces sources sont publiées sous une licence Ms-PL, ce qui implique que vous pouvez changer le code source à votre grès et même le redistribuer comme projet dérivé. Par contre, Microsoft n’acceptera pas les patchs effectués par la communauté. En effet, Ms veut rester maître de son produit.

NB : si vous voulez le code source d’ASP .NET MVC2, veuillez vous rendre sur cette page. Il vous suffit alors de télécharger le fichier mv2-ms-ps.zip.

En conclusion:

J’ai voulu commencer cette série par une partie assez théorique, j’espère que cet article vous aura donné l’eau à la bouche. Je ne dirai pas que ASP.NET MVC est un Framework révolutionnaire. Microsoft n’a finalement fait que reprendre les principales mouvances actuelles du monde du développement web. Mais n’est-ce pas déjà là un grand pas ? En effet, il semblerait que le respect des standards, l’aspect testable et d’extensibilité aient gagné Microsoft. Après des évolutions majeures telles que Linq, Entity Framework, WCF, Silverlight, ASP.NET MVC est assurément une nouveauté d’un poids comparable aux précités.

Plus personnellement, développant des applications en ASP.NET MVC depuis bientôt plus d’un an, je suis toujours aussi conquis par ce framework. Je profite donc de la sortie du release 2 d’ASP.NET MVC pour vous faire partager mes connaissances acquises ses derniers temps. Le prochain article se concentrera sur l’installation de Visual Studio 2010, du framework ASP.NET MVC2 et d’une application de style « hello word » . Ceci afin de vous faire comprendre les principes de vue, de modèle et de controller. Ces bases acquises, je tenterai de continuer cette série par le développement d’un CMS en utilisant les dernières technologies de Microsoft tout en respectant une certaine philosophie agile (TDD, à l’écoute des changements). J’attendrai, bien évidement de votre part un retour constructif afin de me guider au mieux dans ce périple.

Références :

Pro ASP.NET MVC Framework de Steven Sanderson, le bog de mr Rob Conery, le blog de mr Phil Haack, le blog de mr Scott Guthrie et ASP.NET.

Bon alors, pour commencer, on télécharge VS2010, cela se passe ici.

Qu’y a t’il de nouveau dans VS2010 ?  pas mal d’ajouts :

• l’éditeur de code qui devient vectoriel.
• la refonte de la vue hiérarchique.
• le sur-lignage automatique.
• l’auto-génération d’objets.
• la génération de nouveaux rapports de performance.
• et bien d’autres fonctionnalités,…

Avec .NET 4.0, arrive aussi ASP.NET 4.0, ASP.NET MVC 2, le très prometteur Windows Workflow 4.0,…

Pour commencer avec VS2010, un petit truc sympa, personnaliser la page d’accueil de votre VS2010. C’est très simple, vous vous rendez sur C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\StartPages\en, vous allez voir des fichiers XML, ainsi que l’image de présentation VS 2010, donc soit vous changez les fichiers XML, pour par exemple rajouter des liens utiles, une description sur un projet,… Ici, je vais simplement changer l’image et rajouter le logo de ma compagnie. N’oubliez-pas d’être administrateur sur le dossier pour pouvoir modifier à votre grè.

Après avoir modifié l’image et enregistré les modifications, vous relancez VS 2010 et *tadam* :

Bon voilà, c’était l’apéritif avant les plats principaux…

Qu’est ce que le databinding ?

Selon Ms, c’est la méthode qui permet de lier les composants UI (textbox, listbox,…) à la couche métier. En effet, si les données changent dans la couche métier et que le binding est correctement configuré, les éléments UI se mettront à jour automatiquement. Mais l’inverse est également vrai, si l’utilisateur rentre une valuer dans un textbox, par le binding, le changement sera automatiquement reflété dans la couche métier.

Concept du databinding :

fig 1 (from MSDN)

• La databinding est le lien entre l’objet cible (target en anglais) et l’objet source. Chaque Binding possède quatre composants, un “binding target object” (l’objet cible), une “property target” (la propriété cible de l’ojet cible), un “binding source object” (la source de donnée), et un “path” c’est à dire un chemin vers la valeur se trouvant dans l’objet source.

Par exemple, si vous vouler “binder” le contenu d’un Textbox à la propriété Nom d’un objet Humain, votre objet cible sera la TextBox,
la propriété cible sera la propriété Text de l’object Textbox, la valeur à exploité (le “path”) est la propriété source Nom de l’objet source Humain.

• La propriété de l’objet cible que nous voulons manipuler est un “Dependency Property”  traduction une propriété dépendante. Ceci afin de pouvoir lier cette propriété par databinding. Presque toutes les propriétés des éléments UI (textbox, listbox) sont des “Dependence Property” sauf les “Read-Only”. En effet, ces classes dérivent tous du DependencyObject class (voir ici et ici) qui permet de définir des DependencyProperty qui support le binding.
• L’objet source n’est seulement un object CLR personnalisé (un object comme que vous avez créé comme, par exemple, humain), cela pourrait être tout aussi bien, des objets qui proviennet d’ADO.NET, de webservice ou encore, d’un noeud XML qui contient des données.

A noter que pour créer ces liens (ce databind), vous utilisez des BindingOjbects, c’est grâce à ces objets que le lien peut se faire.

La direction du flux de donnée :

figure 2 (from MSDN)

En effet, le flux de données à un sens, comme l’on peut le voir dans la figure 2. Il y a un sens aux flèches. Le flux de donnée va d’un object source vers un objet cible. La propriété name du textbox pourrait être tout aussi bien être la cible que la source. Ce n’est plus la propriété text du TextBox qui se “remplit” de la proriété Nom de l’objet Humain mais c’est maintenant la propriété text du TextBox qui “remplit” la propriété Nom de l’objet Humain. Ceci implique donc trois sens pour les flux de données (noms donnés en anglais).

• One Way: la propriété cible change selon les données de la propriété source mais l’inverse n’est pas vrai. Ceci convient pour les contrôles de type Read-Only.
• Two Way: le flux de données se propagent dans les deux sens, la propriété est tantôt une propriété source, tantôt une propriété cible. Générallement, nous utiliserons Two Way pour les objets de type formulaire. Par exemple, la propriété Text du TextBox et la propriété IsChecked de l’objet CheckBox est par défaut Two Way.
• OneWayToSource: il est l’inverse de OneWay, il met à jour la propriété source lorsqu’il y a un changement dans la propriété cible.
• One Time (ne se trouve pas dans la figure 2): Initialise la propriété source mais les changements futures ne seront pas propagés. Ce type de “binding” (de lien) est utilisé si vous voulez prendre un instantané de l’état de votre couche métier. Il est plus ou moins équivalent au OneWay mais est plus performant, il est donc à utiliser lorsque les valeurs sont statiques.

Comment détecter des changements dans l’objet source (ceci uniquement pour OneWay et TwoWay) ?

L’objet doit implémenter un méchanisme de notification, en implémentant l’interface INotifyPropertyChange (nous verrons pourquoi plus tard).

Que déclenche un changement dans la source ?

Les databindings qui sont TwoWay et OneWayToSource doivent être attentif aux changements de la propriété cible afin de les propagers vers l’objet source. Le sens du flux de données est assuré par la propriété Mode de l’objet Binding.

Cependant, est-ce que la valeur de votre objet source (par exemple la propriété Nom de l’objet Humain) change t’elle lorsque vous être entrain de changer cette valeur (lors de la saisie dans le TextBox) ou après que vous ayez fini (de changer la valeur du TextBox) ?

En fait, c’est la propriété UpdateSourceTrigger qui détermine ce qui va déclencher la mise à jour de l’objet source.

figure 3 (from MSDN)

Si nous regardons la figure 3, les points représentés aux extrémités des flèches illustrent le rôle de l’UpdateSourceTrigger.

Si l’UpdateSourceTrigger à la valeur “PropertyChanged”, dès que la valeur dans le textbox changera, la valeur de l’object source changera également. Par contre, si l’UpdateSourceTrigger à comme valeur “LostFocus”, la valeur de l’objet source sera propagée lorsque nous nous retirerons du TextBox (passer à un autre textbox par ex.). La valeur par défaut de UpdateSourceTrigger dépend de l’objet. Pour un TextBox cette valeur est, par défaut, LostFocus. En effet, si nous devrions propager la valeur à chaque fois que nous entrons une lettre dans le textbox, les performances diminueraient, c’est pour cette raison que la valeur par défaut de UpdateSourceTrigger est LostFocus et non pas PorpertyChanged.

Il existe également pour le textbox une troisième valeur pour UpdateSourceTrigger, Explicit, utilisée par exemple pour mettre à jour la valeur seulement lors d’un clique de bouton par l’utilisateur (plus d’info sur l’UpdateSourceTrigger : ici ).

Créer un Binding :

Passons au pratique, nous allons établir un lien à l’aide de l’objet binding. Je ne vais pas vous le cacher, pour commencer je vais prendre un exemple MSDN.

Nous avons un object source qui est une classe MyData, elle a une propriété string ColorName dont la valeur est rouge. Nous voulons lier la couleur du background à la valeur ColorName de MyData.

Voici le code en XAML : pour plus d’info sur la syntaxt du binding (ici)

Et voici le code C# :

Ce binding est un binding OneWay en effet, la propriété background du TextBox est par défaut OneWay.

figure 4

Le background property de l’object textbox est de type brush, néanmoins nous lui passons un string, ceci fonctionne par une conversion implicite (plus d’info ici).

Spécifier le Binding Source :

Ici le binding source est défini spécifiant une valeur au DataContext. Le DataContext du Window1 est l’objet MyData. TextBoxt hérite de ce datacontext par l’objet Window1 (son parent). En donnant le chemin vers la propriété qui doit être lié dans le background du textblock. Celui-ci sera où prendre ces données. Si nous ne définissons aucune valeur pour le datacontext, le background du textbox ne prendrait pas la couleur rouge.

Nous obtenons alors le résultat suivant :

Il est intéressant de définir le datacontext dans un niveau parent lorsque vous voulez utilisez ce contexte pour plusieurs enfants. Dans le cas contraire, vous pouvez définir ce contexte rien que pour l’élément que vous voulez lier.

La Classe BindingExpression :

Comme défini plus haut, Binding class est la classe haut niveau pour définir un Binding. Le BindingExpression qui est une sous-jacente de l’objet Binding, cet objet permet de maintenir la connexion entre l’objet source et l’objet target. Un objet Binding contient toute l’information et peut être partagée par plusieurs BindingExpression. Une BindingExpression est une expression d’instance qui ne peut partager ses informations, elle contient toute l’information de l’instance du Binding.

myDataObject est une instance de la classe MyData, myBinding est la source de l’objet Binding, MyData est une classe qui contient la propriété string MyDataProperty. Cet exemple lie le contenu text d’une instance de TextBLock myText vers MyDataProperty.

Dans ce cas, vous pouvez réutiliser l’objet myBinding, par exemple, en liant à un propriété d’un TextBlock. A ce moment, il n’y aura qu’un objet Binding mais deux instances de BindingExpression qui se partage l’objet Binding.

DataConversion :

Dans l’exemple précédent, la propriété background du Texbox est lié à une propriété string avec la valeur « Red ». Cela fonctionne car le type Brush est capable de convertir un string en un objet Brush .

figure 5

Comme l’on peut remarquer sur la figure 5, le Type Brush à une conversion par défaut qui permet de convertir un objet de type string en objet de type Brush.

Que se passerait t’il si notre objet source avait un type Color pour la propriété ColorName. Nous devrions implémenter l’interface IValueConverter (pour plus d’info sur IValueConverter, cela se passe ici). De cette manière l’objet binding sait comment convertir un objet Color en objet de type SolidColorBrush.

Par l’implémentation de cette inferface, notre schéma devient alors :

figure 6

Généralement, pour les types cible connus, la conversion par défaut devrait fonctionner. En cas de doute, vous devriez implémenter l’interface IValueConverter.

Voici une liste de cas où l’utilisation de cette interface est préconisée :

• Vos données devront être affichées différement suivant la culture que vous utilisez. Vous pourriez implémenter un convertisseur de change et/ou un convertisseur de date utilisée par une certaine culture.
• La valeur qui est manipulée ne servira pas à changer la propriété Text du Textbox mais d’autres valeurs comme une source d’image, la couleur ou le style de text affiché. Les convertisseurs peuvent alors être utilisés en convertissant des propriétés qui ne semblerait pas lié entres-elles. Comme par exemple, lier la valeur d’un textbox à une couleur de fond pour une cellule d’un tableau.
• Plus d’un contrôle ou même plusieurs propriétés d’un contrôle peuvent être liées à une même source. Générallement, le “Binding” primaire affichera le texte et d’autres types de “Binding” posséderont certaines particularités sur la manière de relier les éléments entre eux, ceci tout en continuant à utiliser la même source d’information.
• Dans le cas où nous utiliserons des MultiBinding , dans ce cas un propriété cible sera lié à une collection de Binding. Dans le cas d’un multibinding vous utiliserez l’interface IMultiValueConverter afin de produire une valeur finale à partir des valeurs contenues dans votre collection de Binding.

Binding to Collection :

Dans un Binding, un objet source peut être soit traité comme un simple objet dans lequel ses propriétés contiennent des données soit comme une collection de données d’objets polymorphiques groupés ensembles (comme le résultat d’une query provenant d’une base de données). Ici nous avons toujours utilisés des objets simples mais nous aurions pu utiliser des ItemsControl comme des ListBox, des ListView, des TreeView afin d’afficher des collections d’objets.

figure 6

Comme l’on peut remarquer dans le diagramme précédent, pour lié un ItemsControl à une collection d’objet, nous devons utiliser la propriété ItemsSource. ItemsSource est en quelque sorte le contenu du ItemsControl. Par défaut la direction du flux de donnée pour un ItemsControl sera OneWay.

Comment implémenter les collections ?

Vous pouvez utiliser n’importe quelles collections qui utilisent l’interface IEnumerable. Pour gérer un binding qui permettrait l’insertion, la suppression ou l’update de donnée automatiquement retranscrite dans l’UI, la collection doit implémenter l’interface INotifyCollectionChange. Cette interface permet d’exposer un évênement qui sera déclenché à chaque changement dans la collection.

WPF founit la classe ObservableCollection(T) qui est une implémentation d’une collection de donnée qui comprend l’interface INotifyCollectionChange. A noter que pour supporter le transfert de données entre l’objet cible et l’objet source, chaque objet dans la collection doit implémenter l’interface INotifyPropertyChange.

Avant d’utiliser votre propre collection, tentez d’utiliser ObservableCollection(T) ou l’une des classes de collection existante comme List(T), Collection(T), BindingList(T), parmis d’autres.

Collection Views

Une fois que votre ItemsControl est lié à un collection de données, vous pourriez vouloir trier, filtrer ou grouper les données. Pour faire cela, vous utilisez les collection views, qui sont des classes qui implémente l’interface ICollectionView.

Que sont les Collection Views ?

Une collection est une couche supérrieur par rapport à une “binding source collection” ce qui vous permet de naviguer et d’afficher la collection source triée, flitrée et groupée en queries, ceci sans changer la source sous-jacente elle même. Une “collection view” maintient également un pointeur vers l’item courant dans la collection. Si la collection source implémente l’interface INotifyCollectionChange, les changements seront déclenchés par l’évênement CollectionChanged  qui sera propagé aux vues.

Parce ques les vues ne changent pas la collection source adjacente, chaque collection source peut avoir plusieurs vues associées à elle. Par exemple, vous pourriez avoir une collection d’objets Task. Avec l’utilisation de vues, vous pourriez afficher la même donnée sous différentes vues. Par exemple, à gauche vous afficheriez les Tasks triées par priorité et de l’autre triée par date.

Commen créer une vue ?

Une façon de créer et utiliser une vue est d’instancier les objets vues directement et les utiliser comme source pour le binding.

figure 7

figure8

Comme nous voyons dans l’exmple ci-dessus qui provient de MSDN, nous pouvons voir que le ListBox à pour Object source un CollectionViewSource lui-même lié à une liste d’objet AuctionItems . Vous pourriez réutililiser ce CollectionViewSource pour un autre type de contrôle, ce qui est important ici est de ne pas oublié de définir le x:Key dans la CollectionViewSource afin de que le contrôle puisse savoir où il va chercher ses données.

Le tableau suivant nous montre quels types de données (vue) sont crées comme CollectionView par défaut (IList -> ListCollectionView). Le résultat serait le même si nous utiliserions un CollectionViewSource afin de créer les CollectionViews.

Utiliser une Default View

Spécifier une collection view comme un “binding” source est une des solutions pour créer et utiliser des collection view. WPF crée également une default collection view pour chaque collection utilisée comme source du binding. Is vous liez directement un contrôle, WPF la lie à sa vue par défaut. Cette vue par défaut est partagée par tout les “bindings” de la même collection, donc un changement fait à la vue par défaut par un contrôle lié ou du code (trier, filtrer,…) est reflétée dans tous les autres bindings de la même collection.

Collection Views avec ADO.NET DataTables

En vue d’améliorer les performances, les collection views pour ADO.NET DataTable ou les DataView délèguent le tri, les filtres au DataView. En conséquent, le tri et le filtrage sera partagé à travers toutes les collections du datasource. Afin de mettre en place le tri et le filtrage sur chaque collection view, vous devez initialiser chaque collection view avec son propre DataView object.

Sorting

Comme mentioné ci-dessus, les vues peuvent trier un collection. Comme il existe dans la collection adjacente, vos données pourraient ne pas être dans un ordre pertinant. La vue au dessous de cette collection adjacente vous permet d’imposer un ordre et de changer l’ordre par défaut, basé sur des critères de comparaison que vous définissez. Parceque c’est un client-based view des données, un scénario commun pourrait être un utisateur qui veut trier les colonnes d’un tableau suivant ses valeurs correspondantes. En utilisant les vues, ce tri personnalisé pourrait être appliqué, et ce, sans faire de changement dans la collection de la couche adjacente et sans devoir faire de query dans cette couche adjacente (plus d’info ici).

Voici un exemple de tri qui trie par Catégorie et par StartDate :

Vous pouvez trouver un exmple de binding intéressant sur MSDN, ici.

Filtering :

Une vue peut également appliquer un filtre à une collection. Cela ne permet d’afficher qu’un sous-esemble d’une collection. Vous pouvez également trier sous des conditions personnalisées.

Voici un exemple de filtre qui provient de la démo fournie par MSDN.

The ShowOnlyBargainsFilter event handler

Grouping :

Exepté pour les classe internal qui sont retranscrite en IEnumerable collection, toutes les collections views supporte la fonctionnalité de grouping. Ceci permets aux utilisateurs de subdiviser la collection dans la collection view dans un groupe logique. Les groupes peuvent être explicite, l’utilisateur fournit une liste de groups ou implitcit, les groups sont générés dynamiquement dépendamment des données.

Voici un exemple de fonction de grouping :

Pointer sur l’item actuel:

Les vues supportent également la notion d’item actuel. Vous pourriez naviguer à travers les objets dans une collection view. Pendant que vous naviguer, vous passez d’un item à un autre et un pointeur d’item vous permet de retirer les informations de l’item actuel.

Comme WPF est lié à une collection uniquement en utilisant une vue, toutes les liaisons vers les collections possèdent ce pointeur d’item. Quand vous liez à une vue le caractère “/” désigne le chemin vers la valeur actuel. Dans l’exemple suivant, le data context est une collection view, le premier binding est lié à la collection, le second binding est lié à l’item actuel de la collection et le troisième est lié à la propriété Description de l’item actuel.

Ex :

Le Master Detail Binding Scenario

La notion d’item actuel est utile pour le Master Detail Binding Scenario. Si nous regardons dans l’exemple ci-dessous où le contenu du ListBox détermine le contenu affiché dans le ContentControl. Vous pouvez déterminer le Master Detail Binding scenario en liant deux ou plus contrôle à une même vue.

Ces deux contrôles sont liés à une même vue (listingDataView). Cette exemple marchera car lorsque un objet singleton (ici ContentControl) est lié à une collection view, il est automatiquement à l’item actuel (CurrentItem) de la vue. Si le list control n’est pas lié à un objet CollectionViewSource comme dans l’exemple, alors, vous devriez définir la propriété IsSynchronizedWithCurrentItem à “true” pour que cela fonctionne. L’exemple ci-dessous ne fonctionnerait pas si il n’utiliserait pas un template (voir prochain article).

DataTemplate :

Je reviendrai dans un prochaine sur l’utilisation de DataTemplate.

En attendant, voici une série de lien qui pourra vous être utiles :

http://msdn.microsoft.com/en-us/library/ms752347.aspx#specifying_the_binding_source

http://msdn.microsoft.com/en-us/library/ms752347.aspx#data_conversion

http://msdn.microsoft.com/en-us/library/ms752347.aspx#data_conversion

http://msdn.microsoft.com/en-us/library/dd458894.aspx

http://msdn.microsoft.com/en-us/magazine/cc163299.aspx

http://odetocode.com/articles/740.aspx

]]> http://www.fr.dervalp.com/?feed=rss2&p=36 http://www.fr.dervalp.com/?p=171 http://www.fr.dervalp.com/?p=171#comments Mon, 23 Nov 2009 12:44:40 +0000 admin http://www.fr.dervalp.com/?p=171 Questions générales :

1) C# supporte t’il l’héritage multiple ?

non

2) Pour qui sont disponibles les variables de type Protected comprises dans une classe ?

Pour toutes les sous-classes de la classe comprenant ces variables de type protected.

3) Est-ce que les variables de type privées sont héritées ?

Oui, mais elles ne sont pas accessibles. Bien qu’elles ne soient ni visibles et ni accessibles, elles sont héritées. Si vous voulez la rendre accessible aux sous-classes, vous devez utilisez une variable protected.

4) Décrire l’accessibilité du “protected internal” ?

Sera disponbile pour les classes qui se trouvent dans le même assembly et qui sont dérivés de cette classe de base.

5) De quelle classe sont dérivés tous les objets en .NET  ?

System.Object.

6) Que veut dire le terme “immutable” (immuable en Français) ?

Que la valeur de donnée (datavalue) ne peut-être changée. La valeur d’une variable peut être changée mais on est alors débarrasé de la valeur de données immuable et une nouvelle valeur de données a été créée.

7) Quelle est la différence entre les classes System.String et System.Text.StringBuilder ?

System.String est immuable. Stringbuilder a été créé pour manipuler des strings muables où des opérations sur ceux-ci peuvent être réalisées.

8 ) Quelle est l’avantage d’utiliser StringBuilder plutôt que String ?

Stringbuilder est plus performant si il faut manipuler un grand montant de string. String est immuable, c’est à dire qu’il recrée une nouvelle instance en mémoire à chaque fois que sa valeur change.

9) Pouvez-vous utiliser plusieurs types dans un System.Array ?

non

10) Quelle est la différence entre System.Array.CopyTo() et System.Array.Clone() ?

La méthode copy retourne un nouvel array (shallow copy (copie peu profonde, frivole)) d’objets contenant tous les éléments de l’array original. La méthode CopyTo() copie les éléments de l’array original dans un array existant. Les deux réalisent une copie peu profonde. Une copie peu profonde est le fait que le contenu (chaque élément d’un array) contiennent les références des mêmes objets que les éléments de l’array orginel. Une copie profonde (deep copy) aurait crée une nouvelle instance de chaque élément de l’objet orignal.

11) Comment trier un array dans le sens décroissant ?

On utilise la méthode Sort() et ensuite la méthode Reverse().

12) Quelle classe de collection peut-on utiliser pour accéder un de ses éléments par une clé d’accès ?

HashTable

13) Quelle classe se trouve à un niveau plus bas de Sorted List ?

Sorted HashTable

14) Dans un try catch, est-ce que le block “finally” sera exécuté si une exeption ne se produit  pas?

oui

15) Quelle est la syntaxe qui permet de saisir toutes les exeptions possibles ?

Un catch qui intercepterait les exeptions de type System.Exception. Si vous utilisez le catch par défaut (catch{}), cela aura le même effet.

16) Peut-on avoir plusieurs catch exécutés lors d’un même try ?

non, le contrôle sera exécuté dans la partie finally du try.

17) Quels sont les 3 parties d’une 3-tiers application ?

Presentation (UI), Business , Data

Question sur les classes :

1) Quelle est la syntaxe pour hériter d’un classe en C# ?

NomdelaClasseEnfant : NomdelaClasseParent

2) Pouvez-vous empêcher une classe d’être hériter par une autre classe ?

Oui en utilisant le keyword “sealed”.

3) Pouvez-vous permettre à une classe d’être héritable mais empêcher qu’une de ses méthodes soit “overrider” ?

Oui, il faut rendre la classe public et la méthode “sealed”.

4) Qu’est-ce qu’une classe abstraite ?

C’est une classe qui ne peut-être instanciée, c’est une classe qui peut être héritée et qui peut posséder des méthodes qui peuvent-être spécialisée  (”overrider”). Une classe abstaite est générallement une emprunte pour d’autres classes.

5) Quand devez-vous absolument définir une classe abstaite ?

- lorsqu’au moins une des méthodes est abstraite

- lorsq’une classe est elle-même héritée d’une classe abstraite et que toute ses méthodes abstraites héritées n’ont pas été redéfinir (”overrider”).

6) Qu’est-ce qu’une interface ?

Les interfaces, comme les classes définissent une série de propriété, méthodes, évênements. Mais contrairement au classe, les intefaces ne fournissent pas d’implémentation. Elles sont implémentées par des classes

7) Pourquoi ne pouvez-vous pas définir d’accesseur pour une méthode à l’intérieur d’une interface ?

Elles doivent toutes être publique, elles sont donc public par défaut.

8 ) Pouvez-vous hériter de plusieurs interfaces ?

oui, .NET supporter le multi-héritage d’interface

9) Pouvez-vous hériter de plusieurs interfaces qui ont des méthodes de même nom et même signature ?

Oui vous pouvez, mais il risque d’y avoir quelques problèmes. Si le compilateur est ok, cela devrait passer. PS : En testant, j’ai remarqué vous pouviez, en effet, hériter de plusieurs interfaces qui ont des méthodes de même nom, mais alors nous devons en choisir une qui sera public, les autres seront marquées privées. Enfin, je déconseillerais de réaliser ce genre de chose.

10) Quel est la différence entre une classe abstraite et une interface ?

Dans une inteface, toutes les méthodes sont abstraites, il n’y pas d’implémentation. Dans une classe abstraite, les méthodes peuvent-être non abstraite mais il n’y a pas d’implémentation. On peut, également, hériter de plusieurs interfaces alors qu’on ne peut hériter que d’une classe abstraite.

11) Quel est la différence entre une struct et une classe ?

Les Strucs sont des variables “value type” et sont donc sauvés dans la stack, ils augmentent la taille en mémoire mais augmentent les performances d’accès. Les structs ne peuvent pas être héritées.

Questions sur les méthodes et les propriétés :

1) Quel est le nom implicite du paramètre qui est passé à l’intérieur de la méthode/propriété set d’une classe?

La réponse est Value. Le type de la donnée value est définie par le type de la propriété qui est déclarée.

2) Que veut dire le keyword “vitrual” devant une propriété et/ou une méthode ?

Que la méthode et/ou propriété peut être redéfinie (”overrider”)?

3) En quoi la redifinission (”overrider”) d’une méthode est telle différente de la surchage d’une méthode (overload) ?

Quand vous redéfinissez une méthode, vous changer le comportement de la classe dérivée (vous spécialisez la méthode à sa classe concrète). La surchage d’une méthode entraîne juste le fait d’avoir plusieurs méthodes avec le même nom dans une classe. Ces méthodes ne possèderont pas la même signature.

4) Pouvez-vous redéfinir (”override”) une méthode et la rendre statique, si celle-ci ne l’était pas dans sa classe de base ?

Non, la signature de la méthode doit rester la même (on ne peut changer override que par virtual).

5) Quelles sont les différentes manières de surcharger une méthode ?

Différents paramètres (data type), nombre de paramètres différents, ordre dont les parramètres sont passés.

6) Si une classe de base à un nombre certain de constructeurs surchargés, et la classe héritée a un certain nombre de constructeurs surchargés également, pouvez-vous forcer l’appel du constructeur de la classe de base depuis la classe spécifique?

oui, ajouter “:base()” et entre les parenthèses, les paramètres que vous voulez réutiliser de votre classe de base.

Events and delegates :

1) Qu’est qu’un delegates ?

Un delegate encapsule un référencement vers une méthode.

2) Qu’est ce qu’un multicast delegates ?

Un délégate qui a plusieurs méthodes référencées (handler), toutes ces méthodes seront appelées.

XML - Documentation :

1) XML est-il sensible à la case ?

oui

2) Quelles sont les différences entre // , /// ,/* */ ?

// => commentaire sur une ligne

/// => commentaire en XML

/* */ => commentaire multi-ligne

3) Comment générer de la documentation depuis des commentaires appartenant à un fichier C# avec un compiler en ligne de commande ?

Compilez le avec la balise /doc

Debugging et questions sur les tests :

1) Quel(s) outil(s) de debugging est fourni avec le sdk .NET ?

- CorDBG : command line debugger. Pour utiliser le CordDBG vous devez compiler en ligne de commande avec l’attribu /debug.

- DbgCLR : le debugger en mode graphique, utilisé par Visual Studio.

2) Que fait la méthode Assert() ?

En debug, assert prend une condition booléene comme paramètre et montre la boîte de dialog error si la condition est fausse. Le programme s’exécutera si la condition est vrai.

3) Quelle est la différence entre la classe debug et la classe trace ?

La documentation semble la même, utilisez la classe debug pour debulg build, utilisez la classe Trace pour les builds debug et release.

4) Où la sortie de TextWriterTraceListener est-il redirigé ?

Soit dans une console, soit dans un fichier, dépendant des paramètres qui lui sont passés.

5) Comment débugger une application ASP.NET ?

Attachez le process aspnet_wp.exe au débugger dbgclr;

6) Quels sont les trois types de test vous devriez tester dans vos tests unitaires ?

- Un cas de test positif : donnée correcte, sortie correcte.

- Un cas de test négatif : donnée incorrecte ou manquante et exécution propre.

- Un cas d’exeption : vérifier si les exceptions sont gérer correctement.

7) Pouvez-vous changer la valeur d’une variable pendant que vous debugger une application C# ?

Oui, si nous débuggons via Visual Studio .NET, se rendre sur Immediate Window.

ADO.NET et Database :

1) Quel est le rôle de la classe DataReader dans ADO.NET ?

Un DataReader retourne un ensemble de row, read-only et forward-only à partir d’un datasource.

2) Quels sont les avantages et les inconvénients des data provider fourni par Microsoft dans ADO.NET ?

SqlServer.NET data provider une solution performante et robuste pour accéder à un serveur SQL. Cependant microsoft fournit une classe OLE-DB.NET qui permet d’accéder aussi-bien des base de données Oracle, DB2,… Cependant, cette couche n’est pas aussi performante et efficace que la couche d’accès pour Sql Server.

3) Quel est le caractère de remplacement (wild card) en SQL ?

Réponse : %, utiliser avec LIKE dans les query SQL.

4) Expliquez les règles d’or ACID pour les transactions ?

Une transaction doit être:

- Atomic : cette unité de travail ne doit pas dépendre des transactions précédentes ou futures.

- Consistent : Les données doivent être conformes et un système de roll-back doit être mis en place. Il ne dois pas y avoir de valeur “in-between”, le cas ou une partie a été mise à jour et pas l’autre.

- Isolated : aucune transaction ne voit le résultat intermédiare de la transaction actuelle.

- Durable :  La donnée doit persistée si elle est conforme même si par après le système plante.

5) Quels types de connections supportent SQL Server ?

Windows Authentication (via Active Directory) et SQL authentication (via SQL Server avec un login et un mot de passe).

6) Entre windows authentication et sql server authentication, lequel est “trusted”, lequel ne l’est pas ?

Windows authentication est trusted car le usernam et le password est vérifié par Active Directory, Sql server est untrusted car il est le seul à participer

7) Qu’est ce que définit le “initial catalog” dans le connexion string ?

le nom de la database

Que fait la méthode Dispose avec l’objet Connection ?

il le supprime de la mémoire.

9) Quel est le prérequis pour un connection pooling ?

La procédures multiples doivent accepter de partarger la même connection, tout les paramètres doivent être les mêmes (paramètres de sécurité inclus). Le connection string doit être identique.

Assembly :

1) Quels sont les possibilités pour déployer un assembly ?

un MSI Installer, une archive CAB, la commande XCOPY

2) Qu’est ce qu’un assembly satellite ?

Lorsque vous écrivez une application multi-lingue et/ou multi-cultures en .NET, vous voulez distribuer le core de l’application séparrément de ces modules localisés. Les assembly localisées sont alors des assembly satellite.

3) Quels sont les namespace à incorporer pour une application localisée ?

System.Globalization et System.Ressources

4) Quelle est la plus petite unité d’exécution en .NET ?

un assembly

5) Quand devez-vous appeler le Garbage Collector en .NET ?

Normalement jamais. Néanmoins, vous pouvez appeler le Garbage collector lorsque vous vous débarasser d’ objets conséquents en mémoire dont vous n’avez plus l’utilité.

6) Quel nom porte l’action de convertir un value-type en reference-type?

Boxing

7) Que se passe t’il en mémoire lorsque vous “boxez” une valute-type en reference type ?

L’objet créé par boxing se mémorisera dans le heap (passage du stack au heap). Unboxing est l’opération inverse, il convertit un type référence en un value-type, c’est à dire passage du heap au stack.

Conclusion :

Je rajouterai au fur et à mesure de nouvelles questions, mon but étant de faire une sorte de FAQ sur le C# à connaître avant de passer une interview.

Voici un exemple de “widening conversion” :

int i = 1;

double d = 1.000001;

d = i ; // convertion OK

Si le type source à un range et une précision plus grande que celle du destinataire on parle alors de “norrowing conversion”. Ceci requiert une conversion explicite. Ce type de conversion est source d’erreur si la valeur source dépasse le range du type destinataire. Dans ce cas, si la conversion entre ces types n’est pas définie, vous recevrez une erreur de compilation.

Autre type de casting donc, le norrowing conversion :

double d = 1.000001;

int i = 1;

i = int (d);

Boxing : C’est convertir un type valeur (int, double, float,…) en un type référence. Ci-dessous nous convertissons un int (type valeur) en un objet (type référence).

int i = 124;

object o = (object) i ;

UnBoxing : C’est convertir un type objet en un type valeur. Convertir un objet en int.

object o = 123;

int i = (int)o;

La pratique du Boxing et de l’Unboxing est assez coûteux en performance et vous devriez éviter de l’utiliser trop souvent à l’intérieur de tâches répétitives. Le boxing intervient également lorsque l’on appele une méthode virtuel d’une structure ou d’un type valeur qui hérite de System.Objet, comme ToString(). Les conseils suivant évitent les boxing non-nécessaires

• Implémenter des méthodes spécifiques par type que nous voulons utiliser. Ceci est utile lorsque cette méthode doit être capable d’interpréter plusieurs types de valeurs.
• Utiliser les génériques plutôt que de coder à partir du system.object.
• Override les méthodes ToString, Equals, GetHash virtual lorsque l’on définit une structure.

Comment implémenter la conversion pour un type personnalisé ?

• Définir les opérateurs de convesion pour simplifier le narrowing  (perte de taille et précision) et le widening (augmentation de la taille et de la précision) entre les types numériques.
• Override la méthode ToString pour définir les conversions vers le type string. Override la méthode Parse pour les conversions depuis string.
• Implémentez System.IConvertible pour permettre la conversion à travers System.Convert. Utilisez cette technique pour définir la conversion spécique aux cultures.
• Implémentez une classe TypeConverter qui permet la conversion lors du design-time pour utiliser les propriétés window de Visual Studio.

Vous pouvez également définir les opérations implicit et explicit pour vos classes personnalisées, de cette manière vous autoriserez le casting (widening et narrowing) pour vos classes.

Voici un exemple d’implémentation de casting pour une classe personnalisée :

Et l’implémentation :

J’espère que ses explications vous serviront à mieux comprendre les conversions en C#. Si vous avez des remarques, n’hésitez-pas à m’en faire part.