déc. 18 2011

[ASP.NET] Introduction MVC 4 - Part 6 : Introduction à la notion de modèle et de validation par l'exemple

Dans ce billet nous allons explorer plusieurs notions de base d'ASP.NET MVC en construisant une petite application de saisie de données. L'objectif est de voir un peu plus MVC en action et de coder, certaines explications ou notions seront étudiées plus en détails dans les prochains billets.

Pour consulter les billets précédents :

 

Spécifications de notre petite application

Vu que les fêtes de fin d'année approchent (et ce n'est pas pour nous déplaire !), nous allons coder une petite application Web sur ce thème. Imaginons que vous organisiez une fête pour le nouvel an et que vous voudriez mettre en place un site Web permettant de gérer les invitations à cette soirée. Afin de rester simple nous nous contenterons des trois besoins fonctionnels suivants :

  • Une page d'accueil pour présenter votre soirée
  • Un formulaire permettant à vos amis de répondre à votre invitation
  • Une page de remerciement pour la réponse, suite à validation de la saisie

Nous allons reprendre le code du projet que nous avons créé dans le billet précédent et y ajouter ces fonctionnalités. Notez que vous pouvez très bien partir d'un projet de type Empty pour la suite. Occupons-nous maintenant du premier point, à savoir la page d'accueil permettant de présenter la soirée. On peut imaginer pas mal de choses, l'utilisation d'une map pour permettre à vos amis de localiser son emplacement, ou encore le visionnage d'un vidéo de présentation, etc. On va rester simple et modifier le code HTML de notre vue HomeView

@{
Layout = null;
}
<!DOCTYPE html>
<html>
<head>
<title>Index</title>
</head>
<body>
<div>
@ViewBag.Bonjour !
<p>
J'organise une Mégateuf pour le réveillon du nouvel-an et tu es invité !! <br />
Si "Mégateuf" ça ne te parle pas, ou si tu n'as jamais vu Wayne's World tu peux dès
à présent répondre par NON à cette invitation <br />
Autrement répond vite si tu seras présent ou pas !<br />
(Map ou vidéo ou autre contenu pour présenter la Mégateuf)
</p>
</div>
</body>
</html>

Si nous exécutons l'application maintenant nous obtenons le résultat suivant. Pour rappel, on ne se préoccupe pas du style pour le moment, concentrons-nous sur les mécanismes :

 

Megateuf

 

Concevoir un modèle de données

Vous devriez le savoir maintenant, dans MVC le M signifie Modèle. On peut dire que c'est la partie la plus importante de l'application. Un modèle est la représentation des objets du monde réel, les processus et les règles qui définissent ces objets de notre application. On parle plus généralement de domaine, c'est pourquoi un modèle est souvent désigné comme un modèle du domaine. Ce modèle contient les objets qui composent l'univers de notre application ainsi que les méthodes qui nous permettent de les manipuler. Les vues et les contrôleurs du domaine sont uniquement là pour présenter de manière cohérente notre modèle. On peut ainsi dire qu'une application MVC bien conçue démarre avec un modèle bien conçu. C'est en se basant sur notre modèle que nous concevons et ajoutons des vues et des contrôleurs. Si dès le départ le modèle est mal pensé, je vous laisse imaginer les conséquences pour la suite.

Notre application ne nécessite pas de modèle complexe. Nous allons créer une classe du domaine, que nous appellerons RéponseInvitation et qui sera chargée de stocker, valider et confirmer une invitation.

Ajout d'une classe de modèle

Comme nous l'avons vue par l'exemple dans le billet précédent, il est plus que recommandé, afin de se faciliter la vie, de respecter la convention MVC autant que faire se peut. Dans cette convention les classes qui composent un modèle sont placées dans le dossier Models situé à la racine de notre application Web. Pour ajouter notre classe du modèle, il suffit de faire un clic-droit sur le répertoire dans l'explorateur de solutions et de sélectionner "Add" puis "Class" dans le menu. Nommez cette classe ReponseInvitation et modifier son code comme ci-dessous :

namespace IntroductionMVC4.Models
{
public class ReponseInvitation
{
public string Nom { get; set; }
public string Email { get; set; }
public string Telephone { get; set; }
public bool? SeraPresent { get; set; }
}
}

 

Ajout d'une action méthode

Le deuxième besoin fonctionnel de notre application et de proposer aux invités un formulaire leur permettant de répondre à l'invitation. Pour ce faire nous avons besoin d'ajouter un lien HTML à partir de notre vue Index.cshtml comme on peut le voir ci-dessous :

<div>
@ViewBag.Bonjour !
<p>
J'organise une Mégateuf pour le réveillon du nouvel-an et tu es invité !! <br />
Si "Mégateuf" ça ne te parle pas, ou si tu n'as jamais vu Wayne's World tu peux dès
à présent répondre par NON à cette invitation <br />
Autrement répond vite si tu seras présent ou pas !<br />
(Map ou vidéo ou autre contenu pour présenter la Mégateuf)
</p>
@Html.ActionLink("Rejoins la Mégateuf !", "ReponseInvitationFormulaire")
</div>

Html.ActionLink est une méthode fournie par le Helper HTML. Le Framework MVC est livré avec une grande collection de méthodes d'assistance qui se révèlent très utiles et vite indispensables pour le rendu des liens HTML, les champs de saisie ou de sélection ou d'autres contrôles personnalisés. La méthode ActionLink prend deux paramètres : le premier est le texte à afficher dans le lien, et le second est l'action à effectuer lorsque l'utilisateur clique sur le lien. Je reviendrais dans un prochain billet sur les différents méthodes du HtmlHelper disponibles, mais vous pouvez jeter un oeil à la documentation MSDN dès à présent. L'execution de notre application donne le résultat ci-dessous :

 

Megateuf2

 

Si vous passez votre souris sur le lien dans le navigateur (comme c'est le cas sur la capture), vous verrez que le lien pointe vers http://monserveur/Home/ReponseInvitationFormulaire. La méthode Html.ActionLink a inspecté la configuration de routage URL de notre application et élaboré que /Home/ReponseInvitationFormulaire est l'URL pour une action appelée ReponseInvitationFormulaire sur un contrôleur appelé HomeController. Notez que, contrairement aux applications ASP.NET Web Forms, les URL MVC ne correspondent pas à des fichiers physiques. Chaque méthode d'action a sa propre URL, et MVC utilise le système de routage ASP.NET pour traduire ces URL en actions.

Si vous cliquez sur le lien vous aurez bien entendu une belle erreur 404, puisque nous n'avons pas créé la méthode d'action qui correspond à l'URL /Home/ReponseInvitationFormulaire. Le code ci-dessous montre cette nouvelle méthode d'action dans la classe HomeController :

public class HomeController : Controller
{
//
// GET: /Home/
public ViewResult Index()
{
int hour = DateTime.Now.Hour;
ViewBag.Bonjour = hour < 18 ? "Bonjour" : "Bonsoir";
return View();
}

public ViewResult ReponseInvitationFormulaire()
{
return View();
}
}

Si nous executons maintenant le code, nous aurons une erreur puisque la vue n'existe pas :

Megateuf3

 

Ajout d'une vue fortement typée

Nous allons ajouter une vue pour notre méthode d'action ReponseInvitationFormulaire, mais nous allons faire quelque chose de légèrement différent : nous allons créer une vue fortement typée. Une vue fortement typée est destinée à générer le rendu pour un type de domaine spécifique. Si nous précisons le type avec lequel nous voulons travailler (ReponseInvitation dans notre exemple), MVC peut créer quelques raccourcis utiles pour nous faciliter la tâche.

Avant toute chose, assurez-vous que votre projet est bien compilé. Si vous avez créé la classe ReponseInvitationFormulaire mais pas encore compilé, MVC ne sera pas en mesure de créer une vue fortement typée pour ce type. Ensuite faite un clic-droit à l'intérieur du code de la méthode d'action ReponseInvitationFormulaire et choisissez "Add View". Dans la boîte de dialogue de création de vue, cochez l'option "Create a strongly-typed view" et sélectionnez ReponseInvitation dans le menu déroulant comme ci-dessous :

MVC Vue Fortement Typée

 

En cliquant sur Add, Visual Studio va nous créer une nouvelle vue et ouvrir par défaut le fichier ReponseInvitationFormulaire.cshtml qu'il vient de créer. Vous remarquerez que le code HTML de la vue commence par un bloc Razor @model. Comme vous le verrez plus bas, c'est la clé d'une vue fortement typée et de la commodité qu'elle offre.

Elaboration du formulaire

Maintenant que nous avons créé la vue fortement typée, nous pouvons construire le contenu de ReponseInvitationFormulaire.cshtml pour en faire un formulaire HTML permettant d'éditer des objects ReponseInvitation. Modifiez le code pour qu'il corresponde à celui-ci :

@model IntroductionMVC4.Models.ReponseInvitation
@{
Layout = null;
}
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>ReponseInvitationFormulaire</title>
</head>
<body>
@using (Html.BeginForm())
{
<p>Ton nom : @Html.TextBoxFor(x => x.Nom)</p>
<p>Ton email : @Html.TextBoxFor(x => x.Email)</p>
<p>Ton téléphone : @Html.TextBoxFor(x => x.Telephone)</p>
<p>
Viendras-tu à la Gigateuf ?
@Html.DropDownListFor(x => x.SeraPresent, new[] {
new SelectListItem() {Text = "Yes, Magateuf Garth !!", Value = bool.TrueString},
new SelectListItem() {Text = "No...", Value = bool.FalseString}
}, "Faîtes votre choix, mais réflechissez bien !")
</p>
<input type="submit" value="Submit ReponseInvitation" />
}
</body>
</html>

 

Pour chaque propriété de la classe du modèle ReponseInvitation, nous utilisons une méthode Helper HTML pour avoir un contrôle de saisie HTML adapté. Ces méthodes nous permettent de sélectionner la propriété de l'objet ResponseInvitation que représentera l'élément input HTML, grâce aux expressions lambdas, comme ceci :

@Html.TextBoxFor(x => x.Telephone)


La méthode TextBoxFor du Helper HTML génère le code HTML qui crée un élément de saisie, définit le paramètre de type sur "text", et définit les attributs id et le nom à "Telephone", le nom de la propriété de la classe de domaine choisie, comme ci-dessous :

<p>Ton téléphone : <input id="Telephone" name="Telephone" type="text" value="" /></p>


Cette fonction bien pratique fonctionne parce que notre vue ReponseInvitationFormulaire est fortement typée, et nous avons spécifié à MVC que ReponseInvitation est le type que nous voulons afficher avec cette vue. Une alternative à l'utilisation des expressions lambda est de se référer au nom de la propriété du type de modèle avec une chaîne, comme ceci : @Html.TextBox("Telephone"). Mais il serait bête de se priver des expressions lambda qui nous empêchent de faire des fautes de frappe sur le nom de la propriété. De plus IntelliSense nous permet de récupérer la propriété automatiquement, comme ci-dessous :

Intellisense


Une autre méthode Helper pratique est Html.BeginForm, qui génère un élément de formulaire HTML configuré pour le submit sur la méthode d'action. Puisque nous n'avons pas passé des paramètres à la méthode Helper, il suppose que nous voulons faire postback vers la même URL. Une astuce consiste à  envelopper dans une déclaration comme ceci :

@using (Html.BeginForm()) {
...contenu du formulaire ici...
}


Normalement, lorsqu'elle est appliquée comme cela, l'instruction using garanti que l'objet est éliminé quand il est hors de portée. Elle est couramment utilisée pour les connexions aux bases de données, par exemple, pour s'assurer qu'elles sont fermées dès que la requête est terminée. Plutôt que de se débarrasser d'un objet, la méthode Helper Html.BeginForm ferme l'élément de formulaire HTML quand il est hors de portée. Cela signifie donc que la méthode BeginForm crée deux balises d'un élément de formulaire, comme ci-dessous :

<form action="/Home/ReponseInvitationFormulaire" method="post">
...contenu du formulaire ici...
</form>

ASP.NET Web Forms ne supporte qu'un seul formulaire côté serveur dans une page Web, généralement codé en <form runat="server">, qui est un conteneur pour les données du ViewState et la logique de postback. MVC n'utilise pas les formulaires côté serveur. Tous les formulaires sont exprimés en utilisant du pur HTML (donc pas de runat="server"), et il est donc possible d'en utiliser autant que nous le souhaitons dans une vue. Contrairement aux Web Forms, MVC n'utilise pas le ViewState et les valeurs des ID des éléments HTML générés lors du rendu ne sont pas modifiés. (Notez qu'ASP.NET 4.0 a apporté pas mal de nouveautés concernant la gestion des ID). Tout cela pour dire que les choses sont différentes avec MVC. Nous reviendrons plus en détails sur le sujet dans un prochain billet de la série.

Maintenant, lorsque nous executons notre application, le formulaire donne ceci dans le browser :

Formulaire Megateuf

Evidemment, on ne peut pas vraiment dire que "ça a de la gueule". Mais le design et l'utilisation des CSS n'est pas le sujet de ce billet. Les vues MVC génèrent du code HTML très propre et pur (au contraire d'ASP.NET Web Forms) et vous avez un contrôle total sur l'agencement des éléments et les classes CSS associées.

Manipulation du formulaire

Nous n'avons pas encore spécifié à MVC ce que nous voulons faire lorsque le formulaire est envoyé au serveur. A ce stade, en cliquant sur le bouton submit, les valeurs saisies sont simplement effacées. Tout simplement parce que notre formulaire envoie les données à la méthode d'action ReponseInvitationFormulaire du HomeController, et cette méthode ne fait que renvoyer la vue une nouvelle fois.

Pour recevoir et traiter les données de formulaire soumis, nous allons ajouter une seconde méthode d'action ReponseInvitationFormulaire en vue de créer les éléments suivants :

  • Une méthode qui répond aux requêtes HTTP GET : Une requête GET est ce qu'un navigateur émet normalement chaque fois que quelqu'un clique sur un lien. Cette version de l'action sera responsable de l'affichage du formulaire vierge lorsque quelqu'un visite /Home/ReponseInvitationFormulaire
  • Une méthode qui répond aux requêtes HTTP POST : Par défaut, les formulaires fournis à l'aide Html.BeginForm() sont présentés par le navigateur comme une requête POST. Cette version de l'action sera chargée de recevoir les données saisies et de décider que faire avec elle.

Gérer les requête GET et POST de manière séparée permet de garder un code plus propre, et surtout d'avoir deux méthodes ayant chacune une responsabilité propre (Rappelez vous le premier S de SOLID : Single Reponsability, pour un petit rappel, c'est ici que ça se passe). Bien sûr nos deux méthodes d'action seront invoquées par la même URL, mais MVC permet de s'assurer que la méthode appropriée soit appelée, selon que nous avons affaire à une requête GET ou POST. Le code suivant montre ces deux méthodes dans la classe HomeController :

public class HomeController : Controller
{
//
// GET: /Home/
public ViewResult Index()
{
int hour = DateTime.Now.Hour;
ViewBag.Bonjour = hour < 18 ? "Bonjour" : "Bonsoir";
return View();
}

[HttpGet]
public ViewResult ReponseInvitationFormulaire()
{
return View();
}
[HttpPost]
public ViewResult ReponseInvitationFormulaire(ReponseInvitation laReponse)
{
return View("Merci", laReponse);
}
}
}

 
Nous avons ajouté l'attribut HttpGet à notre méthode d'action ReponseInvitationFormulaire existante. Ceci indique à MVC que cette méthode devrait être utilisée uniquement pour les requêtes de type GET. Nous avons ensuite ajouté une version surchargée de ReponseInvitationFormulaire, qui prend un paramètre ReponseInvitation et applique l'attribut HttpPost. L'attribut indique à MVC que la nouvelle méthode de traite les demandes POST.

Utiliser la liaison de modèle

Vu avez dû remarquer que pour les requêtes POST notre méthode d'action reçoit en paramètre directement un objet de type ReponseInvitation. Mais par quel miracle ? Comment est fait le lien entre le POST d'une formulaire HTML et l'objet C# de type ReponseInvitation ? La réponse se nomme liaison de modèle (ou Model Binding en anglais), qui est une fonction extrêmement utile de MVC. Les données entrantes sont analysées et les paires clé/valeur sont utilisées pour remplir les propriétés des types de modèle du domaine (ReponseInvitation dans notre cas). Ce processus est à l'opposé de l'utilisation des méthodes Helper HTML, lors de la création des données du formulaire à envoyer au client, nous avons généré des éléments de saisie HTML où les valeurs des attributs id et le nom ont été tirés du nom de la propriété de la classe du modèle (exemple : "Nom", "Telephone", etc.). En revanche, avec la liaison de modèle, les noms des éléments de saisie sont utilisés pour définir les valeurs des propriétés dans une instance de la classe modèle, qui est ensuite transmise à notre méthode d'action de type POST.
La liaison de modèle est une fonction puissante et personnalisable qui élimine le labeur de traiter les requêtes HTTP, nous laissant travailler avec des objets C# plutôt que de traiter avec les valeurs de Request.Form[] et Request.QueryString[]. L'objet ReponseInivtation qui est passé comme paramètre à notre méthode d'action est rempli automatiquement avec les données des champs du formulaire. Je reviendrais plus en détails sur ce sujet prochainement.

 

Utiliser d'autres vues


La deuxième surcharge de la méthode d'action ReponseInvitationFormulaire montre également comment nous pouvons dire à MVC de générer le rendu d'une vue spécifique en réponse à une requête. Voici la déclaration pertinente :

return View("Merci", laReponse);

Cet appel à la méthode View demande à MVC de trouver et générer le rendu d'une vue appelée "Merci" et à passer notre objet ReponseInvitation à la vue. Pour ajouter cette vue, même combat : clic-droit à l'intérieur du code de l'une des méthodes HomeController puis Add View. Nous allons créer une autre vue fortement typée nommée "Merci" et qui utilisera le modèle ReponseInvitation. Celle-ci, étant attaché au HomeController, se situera dans le dossier /Views/Home/Merci.cshtml. Modifions la nouvelle vue afin qu'elle corresponde à ceci :

<body>
<div>
<h1>
Merci @Model.Nom !</h1>
@if (Model.SeraPresent == true){
@:Cool Megateuf !!!!!
}
else{
@:Tu me deçois....
}
</div>
</body>

Ici rien de nouveau, c'est une vue fortement typée, qui utilise les propriétés de ReponseInvitation envoyée depuis la méthode d'action ReponseInvitationFormulaire et qui affichera du contenu basé sur les propriétés de l'objet. Vous remarquerez que la syntaxe Razor est quand même franchement sympa ! Je pense que le prochain billet ou celui d'après sera consacré à ce moteur qui mérite d'être connu et utilisé.

Ajouter la validation

Nous sommes maintenant en mesure d'ajouter la validation à notre application. Si nous ne faisions pas cela, nos utilisateurs pourraient entrer des données incohérentes ou même soumettre un formulaire vide. Dans une application MVC, la validation est généralement appliquée dans le modèle, plutôt que dans l'interface utilisateur. Cela signifie que nous définissons nos critères de validation en un même lieu, et elle prend effet en tout lieu où la classe modèle est utilisée. ASP.NET MVC supporte des règles de validation déclarative définies avec des attributs de l'espace de noms  System.ComponentModel.DataAnnotations. Le code ci-dessous montre comment ces attributs peuvent être appliqués à la classe de modèle ReponseInvitation.

public class ReponseInvitation
{
[Required(ErrorMessage = "Hep Garth, il a oublié de saisir son nom !")]
public string Nom { get; set; }

[Required(ErrorMessage = "Hep Garth, il a oublié de saisir son mail !")]
[RegularExpression(".+\\@.+\\..+", ErrorMessage = "Il est pas bon ton email !")]
public string Email { get; set; }

[Required(ErrorMessage = "Hep Garth, il a oublié de saisir son téléphone !")]
public string Telephone { get; set; }

[Required(ErrorMessage = "Y a pas à hésiter à venir à la Megateuf : Oui ou Non !")]
public bool? SeraPresent { get; set; }
}

Comme indiqué précédemment, nous avons utilisé un booléen nullable pour la propriété SeraPresent. Nous avons fait cela pour que nous puissions appliquer l'attribut de validation requis. Si nous avons utilisé un booléen régulier, la valeur que nous aurions reçus par liaison de modèle ne pourrait être que vrai ou faux, et nous ne serions pas en mesure de dire si l'utilisateur a sélectionné une valeur ou pas. La valeur null sera utilisée si l'utilisateur n'a pas sélectionné de valeur, et l'attribut validation Required provoquera une erreur de validation.

Nous pouvons vérifier pour voir si il y a eu un problème de validation en utilisant la propriété ModelState.IsValid dans notre classe contrôleur :

[HttpPost]
public ViewResult ReponseInvitationFormulaire(ReponseInvitation laReponse)
{
if (ModelState.IsValid)
return View("Merci", laReponse);
else
return View();
}

S'il n'y a pas d'erreurs de validation, nous spécifions à MVC de générer le rendu de la vue Merci comme c'était le cas jusqu'à présent. S'il y a des erreurs de validation, nous générons le rendu de la vue ReponseInvitationFormulaire sans aucun paramètre. Nous avons besoin d'afficher les erreurs de validation à l'utilisateur, et nous pouvons faire cela en utilisant la méthode Helper Html.ValidationSummary dans la vue ReponseInvitationFormulaire, comme ci-dessous :

<body>
@using (Html.BeginForm()){
@Html.ValidationSummary()
<p>Ton nom : @Html.TextBoxFor(x => x.Nom)</p>
<p>Ton email : @Html.TextBoxFor(x => x.Email)</p>
...

S'il n'y a pas d'erreurs, la méthode Html.ValidationSummary crée un élément de liste cachée comme un espace réservé dans le formulaire. Dans le cas contraire MVC rend l'espace réservé visible et ajoute les messages d'erreur définis par les attributs de validation. Voici ce que cela donne :

Validation ASP.NET MVC 4

Ainsi l'utilisateur ne pourra afficher la vue "Merci" tant qu'il n'aura pas respecté toutes les contraintes de validation de la classe ReponseInvitation. Remarquez que c'est quand même bien sympa ce système de validation comparé à ASP.NET Web Forms, de plus qu'il est nécessaire de spécifier ces règles à un seul endroit ! Notez également que les données saisies dans le formulaire ont été préservées et s'affichent à nouveau lors du rendu avec résumé de validation. Là encore, c'est la liaison de modèle qui intervient.

Mettre en avant les champs invalides

Les méthodes Helper HTML qui créent des zones de texte, menus déroulants, et autres éléments ont une fonction très pratique qui peut être utilisée en conjonction avec la liaison de modèle. Le même mécanisme qui préserve les données que l'utilisateur a saisi dans un formulaire peut également être utilisé pour mettre en évidence les champs individuels qui ont échoué les contrôles de validation. Quand une propriété de la classe du modèle a échoué la validation, les méthodes Helper HTML vont générer du code HTML un peu différent. À titre d'exemple, voici le code HTML qu'un appel à Html.TextBoxFor (x => x.Nom) génère quand il n'y a pas d'erreur de validation :

<input data-val="true" data-val-required="Hep Garth, il a oubli&amp;#233; de saisir son nom !" id="Nom" name="Nom" type="text" value="" />

Et voici le code HTML pour un appel à la même méthode Helper lorsque l'utilisateur a oublié de saisir son nom : 

<input class="input-validation-error" data-val="true" data-val-required="Hep Garth, il a oubli&amp;#233; de saisir son nom !" id="Nom" name="Nom" type="text" value="" />

Vous remarquez, en gras, que la méthode Htlper a ajouté une class CSS nommée "input-validation-error". Les différentes méthodes Helper appliquent différentes classes CSS, mais celles-ci peuvent être trouvées dans le répertoire /Content/Site.css que Visual Studio ajoute à tous les projets MVC. Pour utiliser cette feuille de style, nous ajoutons une nouvelle référence dans section head de la vue ReponseInvitationFormulaire, comme ceci :

<link rel="Stylesheet" href="@Href("~/Content/Site.css")" type="text/css"/>

Désormais, lorsque la saisie d'un formulaire est rejetée nous obtenons ceci :

ASP.NET MVC Validation Style


C'est ici que s'achève ce billet. Nous pourrions ajouter de nombreuses choses à cette petite application, mais aussi définir un design plus sympa. Nous avons eu un premier aperçu de l'architecture du framework MVC, l'utilisation du modèle et des vues fortement typées, ainsi que l'utilisation de la validation.

La suite au prochain épisode, et n'oubliez pas de faire la Mégateuf !!! :-)

Tags: , , ,

Commentaires

1.
J.-Luc J.-Luc France says:

Bonjour,

je vais probablement ma lancer dans l'aventure MVC et je me pose des questions sur l'organisation entre MVC et Entity framework : comment organiser les projets pour une meilleure réusabilité, comment organiser les différentes projets pour être utilisés d'un site à l'autre, voire comment gérer le contexte de données, etc.

Cela doit être évident mais je n'ai pas trouvé de texte francophone ou même anglophone qui aborde cette question de l'architecture des différents développements...

Avez -vous des pistes ou pensez-vous aborder ce sujet dans vos prochains posts ?

Et bravo pour votre prose !

Cordialement,

J.-Luc

2.
ink@ ink@ United States says:

Bonjour Jean-Luc,

Pour répondre à votre question (enfin j'espère), j'utilise l'architecture suivante sur mes projets: la couche MVC, une couche Repository, et une couche DAO (qui correspond à Entity Framework chez vous).
La clé est surtout de confier une responsabilité à chaque couche et de ne surtout pas les mélanger (pour ne pas en perdre les avantages). Ainsi, la partie "Controller" de MVC, ne s'occupe exclusivement que de l'affichage de l'interface, rien d'autre!! Si j'ai besoin de récupérer des données ou d'en fournir, alors je passe par le pattern Repository. Plutôt qu'un long discours, voici deux liens qui me semblent pertinents:

www.developpez.net/.../

msdn.microsoft.com/en-us/library/ff649690.aspx

Après avoir lu les deux liens, vous y verrez plus clair. Je vous laisse en déduire les avantages (et les inconvénients?) de ce type d'architecture en 3 couches. Attention! Il est important de conserver la persistance de communication entre les couches: en l'occurence les Models de Mvc.

Après c'est toujours pareil, à vous d'adapter en fonction des paramètres de bases du projet: l'argent, le temps, les ressources... Rien ne vous empêche de modifier les couches (ajouter, supprimer...) au besoin, du moment que l'équipe respecte la démarche. C'est vous qui gérez!

3.
Christophe Christophe France says:

Bonjour,

Quand je crée la méthode POST suivante :

[HttpPost]
        public ViewResult ReponseInvitationFormulaire(ReponseInvitation laReponse)
        {
            return View("Merci", laReponse);
        }
Le "ReponseInvitation " avant laReponse n'est pas reconnu et provoque une erreur. Ai je manqué une étape.

Par ailleurs je ne comprend pas bien l'utilisation du GET & POST à ce moment là du tutorial, malgré l'explication.

Je débute en programmation web et donc MVC...
Merci

4.
Nicolas Nicolas France says:

Bonjour Christophe,

Désolé pour le délai de réponse, j'ai désactivé la notification par mail pour les nouveaux commentaires.

Pour répondre à tes questions :
- ReponseInvitation n'est pas reconnu même après compilation du projet ? As-tu bien ajouté un using pour le namespace de ce modèle ? Il n'y a pas de faute de frappe dans le nom de ta classe ?

- Les attributs HttpGet et HttpPost permettent de limiter les actions à une opération Http précise. GET, selon le protocole Http, est une requête du client au serveur pour récupérer une ressource (html, image, css, script, etc.). Cette opération n'est donc pas sensée modifier l'état du serveur. Dans l'exemple, le GET permet de récupérer notre vue, c'est à dire le formulaire.
A contrario POST est une opération Http sensée modifier l'état du serveur, et dans notre cas est utilisé pour faire un submit du formulaire, et donc d'envoyer la saisie utilisateur au serveur pour qu'il la valide et l'enregistre si possible.
En ASP.NET MVC, la plupart du temps, pour les formulaires on aura deux actions du même nom. Une en GET pour récupérer la vue, et l'autre en POST pour faire un submit de la saisie. Si tu le préfères, rien ne t'empêche de renommer tes actions comme ceci :

[HttpGet]
public ViewResult ReponseInvitationGetFormulaire()
{
    return View();
}

[HttpPost]
public ViewResult ReponseInvitationPostFormulaire(ReponseInvitation laReponse)
{
    return View("Merci", laReponse);
}

En espérant t'avoir éclairé

PS : pour creuser plus loin tu peux également t'intéresser aux architectures RESTful, où tu verras un exemple concret de l'utilisation des différentes opérations Http : GET, POST, PUSH et DELETE. Au passage, dans la version beta d'ASP.NET MVC 4 qui vient de sortir (nous étions encore en Developer Preview au début du mois), ASP.NET Web Api est maintenant intégré à ASP.NET pour faire du REST

Les commentaires sont clos