Développer en ASP.NET

 Active Server Page ASP

====== ASP.NET MVC 4

===== Rappel MVC

==== Modèle 

  * Représentation des données à manipuler

  * Règles de gestion

  * Mécanismes d’accès et de persistance des données

==== Vue

  * Interface utilisateur

  * Représentation graphique du modèle

  * Aucun traitement métier ne doit s’y trouver

Deux moteurs de rendu :

  - Razor

  - ASPX

Plusieurs types de vues :

  * Complète

  * Template

  * Partielle

  * Quels sont les éléments communs à l’ensemble des pages ?

  * Quels sont les éléments répétés au sein d’une même page ?

  * Quels sont les éléments présents uniquement sur une page ?

==== Contrôleur ====

  * Intermédiaire entre le modèle et la vue

  * Traitement des requêtes utilisateur

  * Choix des vues

=== Conception du Contrôleur ===

  * Toutes les classes contrôleurs doivent être nommées « XxxController.cs ». Ce n’est pas un choix esthétique mais le fonctionnement imposé par ASP.Net MVC.

  * Une classe qui hérite de la classe System.Web.Mvc.Controller

Le contrôleur doit répondre aux questions suivantes :

  * Quelles actions dois-je traiter ?

  * Dois-je travailler en POST ou bien GET ?

  * Quelle vue dois-je renvoyer à l’utilisateur ?

  * L’action est-elle exécutée dans un contexte de sécurité valide ?

ViewState

C’est une spécificité d’ASP .NET. Il permet de maintenir l’état des contrôles de la page au travers des différents aller-retours (les « postbacks ») entre le navigateur (le client) et le serveur web ASP .NET.

Par exemple, la saisie de l’utilisateur est sauvegardée par le ViewState au-travers des différents PostBacks, ce qui lui évite de tout retaper à chaque fois !

Le ViewState est matérialisé par un champ de formulaire caché (<input type= «hidden») ajouté automatiquement dans le source de la page.

Il grossit en fonction du nombre de contrôles ASP .NET et du nombre de données stockées dedans (attention au poids de la page).


Peut- on mettre dans le Viewstate une liste d’objets qu’on a loadé ? Quels problèmes ?

Oui mais ces objets doivent être sérialisables et ne doivent pas contenir de données sensibles car ils sont véhiculés sur le réseau à chaque postback. De plus, même si le ViewState est crypté (faiblement), il est disponible dans le source de la page. La règle d’or est de ne jamais faire confiance au client !!

Différence entre Session / Application / Cache / Variable ? Durée de vie de chacun ?

La Session est stockée en mémoire et est spécifique à chaque utilisateur de l’application. Elle a un délai d’expiration glissant qui est par défaut de 20 mins.

L’objet Application représente l’application web. Il sert aussi à stocker des données mais celles-ci seront communes à l’ensemble des utilisateurs. Attention ! Les données resteront en mémoire jusqu’à ce qu’on les retire ou que l’on stoppe le serveur web.

L’objet Cache est également commun à tous les utilisateurs mais par rapport à l’objet Application il apporte en plus la notion d’expiration des données (expiration absolue : la donnée expirera dans 1 heure par ex. Expiration relative : la donnée expirera par ex. dans 30 mins mais son délai d’expiration sera repoussé par ex. de 5 mins à chaque nouvel accès).

Une variable n’existe que dans le bloc de code où elle a été déclarée (dans un bloc if, dans une méthode, etc. …).

Masterpage

C’est un objet ASP .NET qui permet de centraliser la charte graphique commune à plusieurs pages (voire de l’ensemble du site web). Les pages utilisant cette MasterPage ne définiront alors que le code HTML qui viendra s’introduire dans les blocs (ContentPlaceHolder) prévus à cet effet dans la MasterPage.

Une MasterPage est constituée d’un fichier de design (.master) et d’un fichier de CodeBehind (.master.cs).

Global Asax

Le fichier en question est le fichier « Global » de l’application : global.asax.

Il propose en standard des méthodes (Event handlers) appelées lors des principaux évènements survenant sur l’objet Application : Application_Start, Application_End, Session_Start, Session_End, Application_Error, Application_BeginHttpRequest, …

CallBack vs PostBack

Un PostBack survient lorsque l’intégralité de la page est retournée par le client au serveur et intégralement renouvellée.

Un callback est un appel au serveur qui retourne des données. Un callback ne rafraichit pas le ViewState et possède un cycle de vie différent.

EnableViewState and ViewStateMode

Recommendation: Use ViewStateMode, instead of EnableViewState, to provide granular control over which controls use view state.

When you set EnableViewState to false in the Page directive, view state is disabled for all controls within the page and cannot be enabled. If you want to enable view state for only certain controls in your page, set ViewStateMode to Disabled for the Page.

<%@ Page ViewStateMode="Disabled" . . . %>

Then, set ViewStateMode to Enabled on only the controls that actually need view state.

<asp:GridView ViewStateMode="Enabled" runat="server">

By enabling view state for only the controls that need it, you can shrink the size of the view state for your web pages.

ASP.Net Web Form vs MVC

	Web Form	MVC
Cycle de Vie	Cycle de vie fortement basé sur la « page active .aspx ». Le fonctionnement est géré par des évènements auxquels on peut s’abonner	Cycle différent car un contrôleur se charge du model de données puis sélectionne la vue a affiché.
Dépendances	Une page est composé d’une vue et du code-behind attenant. les 2 sont très fortement dépendant.	Le contrôleur sélectionne la vue afficher. Celle-ci ne dépend que du modèle qu’elle va utiliser pour le rendu
Testabilité	Les pages sont difficiles à instancier en dehors d’un fonctionnement normal. Ceci a pour effet de les rendre quasi impossible à tester de manier automatique	Les contrôleurs sont de ‘simples’ classes que l’on peut instancier sans contexte http. Donc facilement testable avec des tests unitaires par exemple.
Gestion de l’état	Les contrôles stockent leur état dans le ViewState. Le ViewState est transmis dans chaque page. Il a tendance à grossir très rapidement.	MVC ne maintient pas d’état des pages, ni de ViewState. Contrôle total de l’application
Les contrôles visuels	Webforms est fortement basé sur des composants visuels comme Winforms. Ceci implique que le code est généré de manière automatique (sans grand contrôle).	MVC n’utilise pas d’évènement ni de code généré. Vous pouvez donc écrire du code HTML propre comme vous le souhaitez.
Extensibilité	L’extensibilité est gérée par les évènements. Vous devez donc vous abonner pour modifier certains comportements.	L’extensibilité est gérée par héritage ou des filtres. Le fonctionnement est simple à comprendre et à débugger.
HTML, JavaScript, Css	Etant donné la présence de contrôles visuels, vous n’avez pas besoin d’avoir de connaissances approfondies en HTML, JS et CSS pour créer des applications. Les composants vont générer le code pour vous.	L’absence de contrôles visuels et de drag & drop nécessite des compétences en développement HTML, CSS et Javascript. En contrepartie, vous pourrez écrire du code jQuery et des requêtes Ajax très simplement.
Apprentissage	Webforms est plus facile à apprendre et permet de créer rapidement des écrans visuels grâce au drag & drop de composants. Le Framework est intéressant pour débuter avec le Web quand on connait déjà Winforms.	Le temps d’apprentissage est un peu plus long car il faut bien comprendre les concepts du Framework. Une fois que vous aurez bien compris ces concepts, vous pourrez développer très rapidement des applications web modernes.

De plus :

• Le « Postback » est une notion utilisée par Webforms mais qui n’existe plus dans MVC. (et c’est tant mieux )

• MVC n’est pas une surcouche à ASP.NET (même si le nommage est ambigu)