Comment déterminer si une page web doit être un contrôle de l'utilisateur web ?

Question

Certains membres de notre équipe sont d'avis que chaque page web de l'application devrait être un contrôle de l'utilisateur web. Ainsi, vous aurez tout votre html + la gestion des événements dans le Customer.ascx, par exemple, et il y aura une page Customer.aspx correspondante qui contiendra le contrôle Customer.ascx.

Voici leurs arguments :

1. Cette pratique favorise la polyvalence, la portabilité et la réutilisation.
2. Même si la page n'est pas réutilisée dans l'immédiat, elle pourrait l'être à l'avenir.
3. Il se peut que la page client doive être déplacée à un autre endroit ou renommée à l'avenir et il est plus facile de déplacer les contrôles utilisateur.
4. Il s'agit d'une recommandation de l'EM pour les nouveaux développements.

S'agit-il vraiment d'une recommandation pour un nouveau développement ? Cette stratégie présente-t-elle des inconvénients ? Je suis d'accord qu'il est agréable d'avoir un contrôle utilisateur à portée de main si le besoin s'en fait sentir, mais il semble exagéré d'appliquer cela à l'ensemble de l'application "juste au cas où nous en aurions besoin plus tard".

Answer 1

1, 2 & 3 : Faire n'importe quoi parce que "vous pourriez en avoir besoin plus tard" est une stratégie horrible.

http://c2.com/xp/YouArentGonnaNeedIt.html

4 : Je n'ai jamais lu cela et je doute sérieusement que MS ait jamais dit quelque chose de ce genre. Peut-être un article aléatoire d'une seule personne qui a une étiquette MS ou a été un MVP ou quelque chose comme ça, et un jeune développeur crédule l'a pris comme une vérité évangélique.

Answer 2

1. Cela complique sérieusement les script côté client car le jiggery NamingContainer va parfois ajouter _ctl0 etc à tout.
2. Je ne pense pas que MS l'ait jamais recommandé. Demande de liens vers la documentation MSDN.
3. Généralement, lorsque vous avez fini d'implémenter quelque chose, et que c'est suffisamment compliqué, vous trouverez de nombreux "gotchas" lorsque vous essayerez de le "réutiliser". Les liens relatifs en sont un bon exemple en le contrôle de l'utilisateur qui ne fonctionnent plus en dehors de leur chemin.
4. Les utilisateurs n'ont pas besoin de pouvoir ajouter/modifier/supprimer des clients sur chaque page. En effet, vous commencez à rencontrer des problèmes de mise en cache si vous avez ce type de contrôles sur chaque page. Par exemple, si vous ajoutez un client sur une page de facture, le contrôle de la facture sera-t-il mis à jour avec le nouveau client ? Toutes sortes de problèmes d'opérabilité entre les contrôles peuvent se manifester. Il est difficile d'argumenter sur ces questions, car, bien entendu, le contrôle utilisateur de chacun sera parfait Il est donc impossible que cela se produise, ha ha, c'est vrai.
5. Voyez s'ils peuvent trouver un exemple dans lequel le déplacement/renommage d'un contrôle utilisateur a réellement permis de gagner du temps, au lieu de le rendre plus compliqué. Dessinez un exemple réel et montrez les avantages et les inconvénients de chacun.

Answer 3

Personnellement, je ne suis pas un fan, je pense que cela ajoute une couche de complexité à l'application qui n'est pas strictement nécessaire aux premiers stades. Si vous avez besoin de réutiliser un composant que vous n'aviez pas pensé réutiliser auparavant, le refactoriser en un contrôle utilisateur à ce moment-là ne devrait pas être très difficile.

Answer 4

Je suis tombé sur une application en .NET 1.1 qui a été écrite comme cela une fois. Quelqu'un a dû entendre cette même "meilleure pratique" erronée et la prendre pour la vérité absolue.

Je suis d'accord pour dire que cela ajoute un niveau de complexité qui n'est généralement pas nécessaire. Je trouve généralement les usercontrols plus utiles pour les parties d'une page qui sont répétées sur plusieurs pages. Si vous pensez réutiliser la page entière... pourquoi ne pas utiliser la page d'origine ?

Je ne comprends pas non plus l'argument du déménagement/renommage. Il n'est pas difficile de renommer/déplacer une page. Si vous faites ce que vos collègues suggèrent, vous vous retrouverez avec une page customers.aspx qui ne contient rien d'autre qu'un fichier orders.ascx ? Je vois plus de confusion/erreurs potentielles avec cette approche qu'en renommant/déplaçant simplement un fichier.