Modèle Vue Contrôleur dot net.

 

 

1.             Introduction.

 

Microsoft propose en alternative à asp net une implémentation du schéma de conception MVC.

Cette implémentation ne concerne que le web.

Vous trouverez de nombreux articles théoriques sur MVC. Par exemple :

 

 

 

 

2.             Cycle de fonctionnement d’une application MVC Dot Net.

 

 

Noter que le schéma adopte une disposition en couche plutôt que le traditionnel schéma en triangle. En effet dans MVC Dot Net, les accès au modèle depuis la vue sont déconseillés.

 

·       La vue est ce qui est affichée sur l’écran du navigateur. C’est du HTML. Elle est générée selon le descriptif de la page décrit dans un fichier aspx.

·       Le ou les contrôleurs sont des classes. Pour chaque URL possible, il existe une méthode dans un contrôleur.

·       Le modèle implémente la logique métier. Il comporte souvent des accès à un SGBD. Il est complètement indépendant de la technique de vue. Il peut par exemple être utilisé depuis un client riche, une application internet ou un téléphone.

 

 

1 action opérateur.

 

En cliquant sur un lien ou en soumettant un formulaire, l’opérateur provoque la demande d’une URL. Cela peut être une requête get ou une requête post.

 

2 Appel modèle.

 

Selon la requête reçue, le contrôleur appelle la méthode appropriée du modèle. Cela peut être une mise à jour ou une recherche, ou toute autre chose. Le contrôleur récupère les résultats retournés par le modèle. Pour une mise à jour cela peut être un code retour, pour une recherche cela peut être une collection. Une stratégie intéressante peut être d’exposer le modèle sous forme de service Web.

 

3 Appel de la Vue.

 

Selon le retour du modèle le contrôleur décide de la vue qui doit être affichée. Il construit un ViewModel contenant les données à afficher et la transmet à la vue. La syntaxe permet de passer directement des éléments du modèle, mais cela est déconseillée, il faut bien séparer la vue et le modèle ; ne donner à la vue que ce qui lui est nécessaire.

 

3.             Fonctionnement détaillé.

 

3.1.                  Routage des URL vers une méthode d’un contrôleur.

 

Ce routage est défini dans le fichier global.asax, voici son contenu par défaut :

 

     routes.MapRoute(

         "Default", // Route name

          "{controller}/{action}/{id}", // URL with parameters

           new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults

            );

 

Cela signifie que par défaut : la méthode index du contrôleur home sera appelée.

 

Et voici une URL get type :

 

http://localhost:50880/Home/truc?id=5

 

 

·       Home est le contrôleur, c’est la valeur par défaut définie par MapRoute.

·       Truc est la méthode, la valeur par défaut était index.

·       Id est un paramètre, optionnel ici.

 

3.2.                  Traitement dans le contrôleur.

 

3.2.1.                      Requête GET.

 

Voici un exemple type en réponse à l’URL ci dessus :

 

   public ActionResult truc(int id)

        {

            if (id == 0)

            {

                // on spécifie la vue  à appeler

                return View("tric");

            }//fin cas spécial.

 

            else

            {

                // Appeler le modèle

                // Ici multiplier id par 2

                Calculatrice cal = new Calculatrice();

                int res;

                cal.load(id);

                res = cal.mult(2);

 

                //construire le ViewModel

                ViewTruc v = new ViewTruc();

                v.Message = res.ToString();

 

                // Par défaut appelle la vue truc

                // Et on passe le modèle en paramètre

 

                return View(v);

            }//fin cas normal

        }//fin méthode

 

Le paramètre de l’URL (id=5) est récupéré comme paramètre de la méthode.

Ici si la valeur du paramètre est zéro le contrôleur appelle la vue tric.

Sinon

·       On appelle le modèle : ici une instance de Calculatrice.

·       Puis pour retourner des informations à la vue, le contrôleur crée une instance de ViewModele de la classe ViewTruc.

·       Pour terminer on demande la génération de la vue par défaut truc et on transmet le ViewModel v.

 

 

 

3.2.2.                      Requête POST.

 

Si la vue doit passer au contrôleur des informations complexes, il est préférable qu’elle utilise un formulaire et la méthode POST.

 

La vue doit d’abord déclarer la classe de donnée à saisir :

 

 <%@ Page Title="" Language="C#"

Inherits="System.Web.Mvc.ViewPage<musicStore.Models.article>" %>

 

Ensuite, par exemple, définir un formulaire :

 

   <% using (Html.BeginForm())

{%>

        <fieldset>

                <%: Html.TextBoxFor(model => model.CodeArticle) %>   

                <%: Html.TextBoxFor(model => model.Designation) %>           

                <%: Html.TextBoxFor(model => model.Prix) %>

                <input type="submit" value="Create" />

        </fieldset>

 

    <% } %>

 

Dans ces conditions le contrôleur récupère aisément les saisies :

 

        [HttpPost]

        public ActionResult Create(article nouvelArt)

        {

 

3.2.3.                      Gestion de l’état.

 

On pourrait espérer que le contrôleur gère l’état dans ses données membres. Il n’en ait rien.

Vous devez utiliser un mécanisme de persistance. Les variables de sessions conviennent.

3.3.                  La Vue.

 

La mission de la vue est de saisir ou d’afficher des données. Rien de plus.

La vue ne doit pas contenir de code, la vue est définie dans un fichier aspx comme pour les web forms, mais il n’y a pas de code behind.

Nous avons vu ci-dessus comment saisir ; examinons maintenant comment afficher.

Les données à afficher sont donc transmises depuis le contrôleur via une instance de ViewModel.

Le type de ce ViewModel est défini au début de la vue ; par exemple :

 

<%@ Page Title="" Language="C#"

Inherits="System.Web.Mvc.ViewPage<MvcApplication.ViewModels.ViewTruc>" %>

 

Ensuite l’affichage peut se faire membre à membre comme ceci :

 

  <h1>truc</h1>

    <h2><%: Model.Message %></h2>

 

 

On retrouve donc le style de programmation de php ou de l’ancien asp. Cependant les données ne sont par calculées dans la page. Les seules instructions de programmation autorisées sont les boucles telles que :

 

<%

foreach (String unGenre in Model.Genres)

      {

 

      }

 %>

 

Utile pour afficher un tableau.

 

Et les if pour le cas où l’affichage dépendrait de la valeur d’une donnée, par exemple :

 

<%if (Model.Genres.Count == 0)

      {%>

      <p>La liste est vide</p>

 

<% } %>

 

4.             Mise en œuvre avec Visual Studio 2010.

 

Visual Studio 2008 et surtout Visual Studio 2010 offrent une aide appréciable.

Il faut parfois demander à installer les extensions MVC.

 

Choisir un projet :  ASP Net MVC2 Web application.

 

Visual Studio organise les fichiers en :

Il est conseillé d’ajouter

 

 

Vous pouvez enlever ce qui concerne l’identification et l’inscription.

 

 

 

 

 

Cet exemple est développé pas à pas dans une vidéo de Scott Hanselman:

 

http://channel9.msdn.com/posts/matthijs/ASPNET-MVC-2-Basics-Introduction-by-Scott-Hanselman/

 

5.             Pour en savoir plus :

 

Il faut bien évidemment visiter le site de Microsoft, où tout cela est expliqué.

 

http://www.asp.net/mvc

 

6.             Discussion.

 

Dans les technologies Microsoft vous aurez le choix entre :

 

Si vous opter pour MVC, vous avez aussi en Java des framewoks MVC célèbres :

 

Si l’on compare les framework MVC entre eux, celui de dot net présente la caractéristique de permettre la programmation libre du contrôleur, alors que la plupart des frameworks ne vous laisse organiser la navigation que via un fichier de configuration. En java le code de la servlet contrôleur vous est caché.

 

Mais faut-il utiliser MVC ?

 

6.1.                  Avantage :

 

Le point impératif est de séparer la vue et le modèle. Pour cela MVC n’est pas indispensable, il suffit de programmer des classes métiers que la vue appelle. C’est facile avec asp dot net et les WebForms.

 

La question est donc : la couche contrôle est elle indispensable, plus précisément :

 

Si vous répondez oui à l’une de ces questions, il y a bien un besoin de contrôle. C’est pourquoi le contrôleur est souvent un automate d’états finis.

 

Si malgré tout  vous décidez de ne pas utiliser MVC, vous serez probablement conduit à introduire un aspect contrôle dans certaines de vos vues (par exemple avec des instructions redirect).

 

6.2.                  Inconvénients :

 

MVC à la réputation d’être lourd à mettre en œuvre. Avec le framework MVC Dot net, les choses sont cependant assez claires. Par contre vous ne disposez plus des assistants de asp Dot Net. La réalisation des vues peut être laborieuse, un peu comme en php.

 

Retour au menu général.