Conseils pour éviter les grosses boules de boue avec ASP.NET WebForms

Question

Bien qu'ASP.NET MVC semble avoir tout le battage médiatique de nos jours, WebForm est toujours très répandu. Comment maintenez-vous votre projet sain d'esprit? Collectons quelques astuces ici.

Answer 1

• Créez des contrôles utilisateur Web pour tout ce qui sera affiché sur plus d'une page qui ne fait pas partie du contenu de type page maître. Exemple: si votre application affiche des informations sur le produit sur 10 pages, il est préférable de disposer d’un contrôle utilisateur utilisé sur 10 pages plutôt que de découper le code d’affichage 10 fois.
• Mettez le moins de logique métier possible dans le code. Le code qui se trouve derrière doit être confié à votre couche métier pour effectuer le travail qui n'est pas directement lié au fait de placer des éléments sur la page et à l'envoi de données à partir de la couche métier.
• Ne réinventez pas la roue. J'ai constaté que beaucoup de codes négligés sont constitués de code qui fait ce que le framework fournit déjà.
• En général, évitez les blocs de script dans le code HTML.
• Vous n'avez pas une page à faire trop de choses. Quelque chose que j'ai vu maintes et maintes fois est une page qui dit a ajouter et modifier les modes. C'est très bien. Toutefois, si vous avez plusieurs sous-modes à ajouter et à modifier, il est préférable de disposer de plusieurs pages pour chaque sous-mode et de pouvoir les réutiliser via les contrôles utilisateur. Vous devez absolument éviter de créer un groupe de FI imbriqués pour déterminer ce que votre utilisateur essaie de faire, puis d'afficher les éléments corrects en fonction de cela. Les choses deviennent rapidement incontrôlables si votre page a plusieurs états possibles.
• Apprenez / appréciez le cycle de vie des pages et utilisez-le à votre avantage. De nombreuses pages de code laides que j'ai vues pourraient être plus propres si le codeur comprenait mieux le cycle de vie des pages.

Answer 2

J'essaie généralement de rester à l'écart ... mais lorsque j'utilise WebForms, je respecte ces préceptes:

1. Conservez le code HTML obtenu : le simple fait de ne pas coder à la main chaque <div> ne signifie pas que le code généré doit devenir un cauchemar illisible. Éviter les contrôles qui produisent un code laid peut s'avérer rentable en temps de débogage réduit, en rendant les problèmes plus faciles à voir.
2. Réduire les dépendances externes : vous n'êtes pas payé pour déboguer le code d'autres personnes. Si vous choisissez de vous fier à des composants tiers, récupérez le code source afin de ne pas perdre de temps anormal à réparer leurs bogues.
3. Évitez de trop en faire sur une page : si vous êtes en train de mettre en œuvre des & modes; complexes & ";" pour une page donnée, envisagez de la diviser en plusieurs pages monomodes, en utilisant éventuellement des pages maîtres pour éliminer les aspects communs.
4. Éviter les publications : cette idée a toujours été terrible et n'a pas été moins mauvaise. Les maux de tête que vous économiserez en n'utilisant pas les contrôles qui dépendent de la publication sont un bonus intéressant.
5. Évitez VIEWSTATE : voir les commentaires pour # 4.

Answer 3

Pour les projets de grande envergure, la meilleure suggestion que je puisse vous donner est de suivre un modèle de conception commun auquel tous vos développeurs sont bien formés et très conscients. Si vous avez affaire à ASP.NET, les deux meilleures options pour moi sont les suivantes:

o Présentateur de vue modèle ( bien qu'il s'agisse maintenant du Contrôleur de supervision et de la vue passive ).   Il s’agit d’un modèle solide qui sépare votre interface utilisateur du modèle commercial que tous vos développeurs peuvent suivre sans trop de difficultés. Le code résultant est beaucoup plus testable et maintenable. Le problème est qu’il n’est pas appliqué et que vous devez écrire beaucoup de code de support pour implémenter le modèle.

o ASP.NET MVC   Le problème avec celui-ci est qu'il est en aperçu. J'ai parlé à Tatham Oddie et il a été mentionné qu'il est très stable et utilisable. Je l’aime bien, cela impose la séparation des préoccupations et le fait avec un minimum de code supplémentaire pour le développeur.

Je pense que quel que soit le modèle que vous choisissez, le plus important est de disposer d'un modèle et de vous assurer que tous vos développeurs sont en mesure de s'en tenir à ce modèle.

Answer 4

Commencez par Master Pages le premier jour - c’est pénible de revenir à l’équipement ultérieur.

Answer 5

Suite à ce qu’a dit Odd, j’essaie une version du MVP appelée Model Presentation, qui fonctionne bien pour moi jusqu’à présent. Je suis encore en train de le comprendre et de l’adapter à mon usage personnel mais cela rafraîchit à partir du code que j’écrivais.

Découvrez-le ici: Modèle de présentation

Answer 6

Utilisez un contrôle de version et une structure de dossiers pour éviter que trop de fichiers ne se trouvent tous dans le même dossier. Il n’ya rien de plus pénible que d’attendre que l’Explorateur Windows charge quelque chose car il y a plus de 1 000 fichiers dans un dossier et il doit tous les charger à l’ouverture du dossier. Une convention sur la dénomination des variables et des méthodes est également utile si possible afin d'éviter tout ce méli-mélo de code dans lequel différents développeurs mettent tous leur touche unique et que cela se voit douloureusement.

L'utilisation de modèles de conception peut être utile pour organiser le code et le faire évoluer correctement, par exemple. un modèle de stratégie peut conduire à une période plus facile lorsqu'il faut ajouter un nouveau type de produit ou de périphérique à prendre en charge. Semblable pour l’utilisation de certains modèles d’adaptateur ou de façade.

Enfin, déterminez les normes que vos formulaires vont respecter: s’agit-il uniquement des utilisateurs d’Internet Explorer ou est-ce que l’un d’entre eux, IE, Firefox ou Safari, peut facilement charger le formulaire et lui donner une belle apparence?