Comment choisir si une page Web doit être un contrôle d'utilisateur Web?

Question

Quelques membres de notre équipe sont d'avis que chaque page Web de l'application doit être un contrôle de l'utilisateur Web. Par exemple, vous aurez tout votre traitement des événements html + dans Customer.ascx, et il y aura une page Customer.aspx correspondante qui contient le contrôle Customer.ascx.

Ce sont leurs arguments:

1. Cette pratique favorise la polyvalence, la portabilité et la réutilisabilité.
2. Même si la page n'est pas réutilisée pour le moment, elle pourrait l'être dans le futur.
3. Il se peut que la page du client doive être déplacée vers un emplacement différent ou renommée dans un futur et que les commandes utilisateur en mouvement soient plus faciles.
4. Ceci est une recommandation de MS pour un nouveau développement.

Est-ce vraiment une recommandation pour le nouveau développement? Y a-t-il des inconvénients à cette stratégie? Je suis d'accord sur le fait qu'il est bon d'avoir un contrôle d'utilisateur en main si le besoin s'en fait sentir, mais il semble que ce soit excessif de le faire pour toute l'application "juste au cas où nous en aurions besoin plus tard".

Answer 1

1. Sérieusement complique le script côté client car le jargon NamingContainer ajoutera _ctl0 etc.
2. Je ne pense pas que MS l'ait jamais recommandé. Demander des liens vers la documentation MSDN.
3. Typiquement, au moment où vous avez terminé la mise en œuvre de quelque chose, et il est suffisamment compliqué, vous trouverez beaucoup de "gotchas" lorsque vous essayez de le "réutiliser". Un bon exemple est les liens relatifs dans le contrôle de l'utilisateur qui ne fonctionne 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 à entrer dans les problèmes de mise en cache si vous avez ce type de contrôles sur chaque page. Par exemple, si sur une page Facture, vous ajoutez un client, le contrôle Facture sera-t-il mis à jour avec le nouveau client? Toutes sortes de problèmes d'opérabilité inter-contrôle peuvent se manifester. Ces questions sont difficiles à argumenter car, bien sûr, le contrôle de tous les utilisateurs sera parfait, donc cela n'arrivera jamais. ha ha droite.
5. Voyez s'ils peuvent trouver un exemple où déplacer/renommer un contrôle utilisateur en fait gagner du temps, au lieu de le rendre plus compliqué. Dressez un exemple concret et montrez les avantages et inconvénients de chacun.

Answer 2

Personnellement, je ne suis pas un fan, je pense qu'il ajoute une couche de complexité à l'application qui n'est pas strictement nécessaire au début. Si vous avez besoin de réutiliser un composant que vous n'aviez pas pensé précédemment être réutilisé, le refactoring dans un contrôle utilisateur à ce stade ne devrait pas être très difficile.

Answer 3

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

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

4: Je ne l'ai jamais lu cela et doute sérieusement MS n'a jamais dit quelque chose comme ça. Peut-être un article aléatoire par une seule personne qui a un tag MS ou était un MVP ou quelque chose, et un junior dev crédule l'a pris comme Gospel Truth.

Answer 4

Je suis tombé sur une application dans .NET 1.1 qui a été écrite comme ça une fois.Quelqu'un a dû entendre cette même «bonne pratique» erronée et l'a pris pour la vérité absolue. Je suis d'accord que cela ajoute un niveau de complexité qui n'est généralement pas nécessaire. En général, je trouve que les contrôles usuels sont plus utiles pour quelque chose comme des 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 déplacement/changement de nom. Ce n'est pas si difficile de renommer/déplacer une page. Si vous faites ce que suggèrent vos collègues, vous obtiendrez une page customers.aspx qui ne contiendra qu'un fichier orders.ascx? Je vois plus de confusion/d'erreurs potentielles avec cette approche que simplement en renommant/déplaçant un fichier.