Architecture

MVC ou pas MVC ?

Un site en ASP.Net peut être mis en œuvre de bien des manières :

> La façon "crade"

Style ASP ou PHP scripté, une page = un fichier.

Dans ce cas, bonjour le mélange entre le code et la présentation. Il est clair que, même si ce type de développement est possible, il est loin d'être recommandé. Oublions le tout de suite...

> La façon ASP.Net basique

Déjà là, la présentation est séparée du code. C'est un bon début.

Dans une approche purement événementielle, ce mode de développement se rapproche des développements d'avant la démocratisation du modèle MVC. Adaptée à un projet de quelques pages, cette méthode de développement ne montre pas toute la puissante de l'architecture .Net. Cependant, c'est une très bonne alternative aux langages scriptés et ça permet de démarrer sur ce framework.

Débutant ? Passez par là avant de vous aventurer plus loin.

> La façon officielle et complète

Le framework .Net défini une organisation des sites permettant de découper encore davantage les programmes afin de permettre une maintenabilité, un découpage et une réutilisation plus forte : Les classes sont alors d'un coté, la vue de l'autre et un "bout de code" au milieu.

Avec une telle explication, il est fréquent d'entendre que le modèle MVC est alors mis en place. Ce n'est que partiellement vrai. En effet, le "bout de code" reste orienté événementiel et relativement couplé à la présentation. Par ailleurs, il n'y a pas de contrôleur centralisé donc il est clair que le modèle MVC 2 n'est pas respecté dans ce cas.

Néanmoins, le fait que ce modèle ne soit pas MVC n'est pas un problème car il fonctionne bien, il est clair et aisément maintenable.

> ASP.Net MVC

Microsoft a cependant voulu satisfaire les connaisseurs du MVC en proposant ASP.Net MVC : Il s'agit d'un mode de développement alternatif au mode ASP.Net classique évoqué précédemment et vraiment MVC.

Du Viewstate

.Net a une particularité unique par rapport aux autres langages de développement Web : Le Viewstate.

Il s'agit d'un moyen d'optimiser les pages en conservant l'état des différents contrôles afin d'éviter d'avoir à repositionner ou recharger des éléments. Le principe est original, mais rapidement des problèmes peuvent se poser si cette notion est oubliée.

En effet, le viewstate peut rapidement devenir énorme et alourdir d'une part votre page et mais également la moindre soumission de formulaire. Cela peut aller jusqu'au point où .Net refusera la soumission du formulaire car il est trop gros et rentre en conflit avec la taille maximale définie pour des questions de sécurité.

Ainsi le viewstate doit être surveillé et géré finement. D'ailleurs, c'est pour cela que Microsoft a choisi avec la version 4 de son framework d'inverser la logique par défaut : Auparavant, le viewstate était activé par défaut pour tous les contrôles, à partir de la version 4, c'est l'inverse. Evidemment, ceci complique pas mal les montées de version des sites ou applications d'une version de framework inférieure à 4 aux versions actuelles...