[Réflexion] Ou placer le code d'une grosse page aspx?

Bonjour,
En développant des pages aspx relativement "complexe", j'ai vite vu mon code-behind grandir et devenir une poubelle.

Je m'interroge sur l'endroit où placer le code dont j'ai besoin. Initialement je mettais tous ce code dans ma page aspx.cs. Mais je me rend bien compte que ce n'est pas une bonne solution. En dehors de ça, ce n'est pas non plus au modèle de connaitre les détails du format à renvoyer pour chaque vues.

Par exemple, j'ai un modèle et une vue.

La vue
-------
Elle contient une gridView et lors d'un clic sur une case de celle-ci, cela crée un pop up contenant une autre gridView. Cette seconde gridView requiert une manipulation du modèle pour l'affichage( pas de modification). Mais par après elle servira pour éditer le modèle.

J'identifie plusieurs bout de code :

1. du code pour remplir ma première gridView (modèle->Get() )
   (créer les colonnes de la gridview, créer et setter la datatable, ...)
2. du code pour remplir ma seconde gridview
   (créer les colonnes de la gridview, créer et setter la datatable, ...)
3. du code pour modifier le modèle
4. du code pour gérer différent boutons (export, save layout, ...)
5. un tas de morceau de code différents qu'il peut exister pour gérer une page aspx.

Quelle solution votre expérience vous a fait adopter ?

J'ai quelques petites idées mais sans trop de convictions.

le code behind peut vite devenir une poubelle, c'est clair. Mais cela peut aussi facilement s'organiser afin d'y voir plus clair.

Déjà tu organises tes grands évènements en suivant le cycle de vie de ta page.

Citation:

---

OnInit
PageLoad
PreRender

---

Tu peux ensuite rajouter deux régions :

Code:

---

1 2 3 4 5 6

OnInit PageLoad region click events region cdatabinding events PreRender

---

Ensuite un région privée pour tes fonctions en début de ta classe :

Citation:

---

region private functions
OnInit
PageLoad
region click events
region cdatabinding events
PreRender

---

Organiser tes déclarations d'objets dans ta page en respectant un ordre :

Citation:

---

region private
region protected
region public

region private functions
OnInit
PageLoad
region click events
region cdatabinding events
PreRender

---

quitte à créer aussi une région pour ca. Tu verras déjà que ton code behind aura plus de gueule et sera plus facile à exploiter.

Normalement ceci devrait résoudre tes soucis. Si ce n'est pas le cas, c'est qu'il y a du code dans tes pages qui devrait être à un niveau supérieur.

Citation:

---

Envoyé par Arthis

Normalement ceci devrait résoudre tes soucis. Si ce n'est pas le cas, c'est qu'il y a du code dans tes pages qui devrait être à un niveau supérieur.

---

Quand tu parles de niveau supérieur tu penses à quoi ? Niveau d'abstraction, niveau d'héritage, ... ?

Je pense justement qu'il y a du code qui devrait ne pas se trouver là, notamment ceux qui construise les DataTable. Un code qui connait bien le modèle et en même temps les exigences de la vue et ses détails. Je pensais donc à une interface entre la vue et le modèle, qu'en penses-tu ?

Poste le code d'une de tes pages ou tu trouves qu'il y en a de trop et on verra ensemble ce qu'on peut faire avec.

Bon, mon grain de sel...

Perso, je n'aime pas les regions, parce que ca a un effet "je te cache la poussière sous le tapis"

Tu as plusieurs niveaux d'action possible

Citation:

---

'il y a du code qui devrait ne pas se trouver là, notamment ceux qui construise les DataTable.

---

Oui, déja, celui-là, il devrait clairement être ailleurs

Il faut ne garder dans le code de la page que ce qui est relatif à de l'affichage.

Idéalement, il faudrait même avoir une classe presenter en rab, qui te manipule les données de tes objets métier pour que ta page web ne fasse que relier des événements avec des fonctions métier (grosso modo, ta page commence par appeler la classe de presentation, en se passant elle-même ainsi que la ou les classes responsables de fournir les données, et la classe de présentation gère les interactions Vue<->Modèle...)

Je pense qu'il faut imaginer deux gros morceaux :
une partie intelligente qui fait tout le boulot (avec des sous niveaux...)
et une autre qui présente le résultat

Au final, queque soit ta couche de présentation, l'application se comporte de la même façon...

Sans forcément faire des Services webs, tu pourrais faire quelque chose d'équivalent : le code behind appel les traitement tous faits extirpe les infos pour les passer aux composants... dans l'autre sens les paramètres sont envoyés à cette couche "cerveau" qui travail...
Dans mon idée, tu aurais une sorte de moteur utilisable par une appli web ou winform ou je ne sais quoi

Du coup ton code behin s'occupe de ce qui est spécifique à ta couche de présentation et fait les appels au cerveau...

Citation:

---

Perso, je n'aime pas les régions, parce que ca a un effet "je te cache la poussière sous le tapis"

---

Il y a un petit effet cache poussière indéniable. Maintenant, je trouve cela plus sympa d'arriver sur une page avec deux trois régions car cela permet une meilleure visibilité souvent de ce que je recherche.

personnellement mes pages sont toutes organisées selon ce type

Citation:

---

OnInit
PageLoad
region click events
region databinding events
PreRender

---

Ensuite je vous rejoins, il ne faut pas faire un accès à sa base de données dans le page_load! :aie:

Donc concernant la séparation du code, je crée 1 Presenter par page aspx ?

Page.aspx.cs <-> PagePresenter.cs <-> Modele

Si j'ai bien compris, ca donne ça :

1. La page (page.aspx.cs) demande au presenter les informations requises à afficher et ce sous la bonne forme
2. Le presenter demande au modele les informations et la structure de façon à ce qu'elle soit directement exploitable par la page

Est-ce bien ça ?
En fait en vous voyant prononcer le mot presenter ca me fait penser à MVP ... Ca doit avoir un rapport j'imagine.

Concernant la structure au sein du fichier aspx.cs, j'aime beaucoup l'idée d'agencer ça selon le cycle de la page comme Arthis mais ça c'est plus une question de gout.

Pour ma part j'utilise 4 Regions :

Events
Methods
Fields
Constructors

Sinon as tu des parties reutilisables ? penses aux UserControl, ou a des classes communes ou separations par des couches.

Oui c'est le modele MVP. Le presenter push les donnees vers la page aspx