Avoir du mal à comprendre les contrôles utilisateur en C #

Question

Je suis nouveau dans le domaine des contrôles utilisateur, je n’en ai créé qu’un, mais supportez-moi. J'ai lu aujourd'hui que les contrôles utilisateur sont supposés être autonomes et ne dépendent d'aucune information du conteneur parent. Je comprends cette partie, mais ce que j’ai du mal à comprendre, c’est le & "Right &"; façon de concevoir mon programme autour de ce principe.

Je crée un formulaire Web en C # dans lequel figure une page avec un contrôle utilisateur. J'ai créé le contrôle utilisateur dans son fichier ascx et je l'ai fait glisser dans ma page aspx. La commande usercontrol est composée de deux boîtes de date et d'une grille permettant d'afficher les résultats d'une procédure stockée SQL.

J'aimerais vraiment réutiliser ce contrôle, mais je ne vois pas comment & "Tell &"; la procédure usercontrol que je voudrais exécuter pour la page spécifique sur laquelle je me trouve sans violer le & "; ne comptez pas sur le conteneur parent &"; règle.

Merci

Answer 1

Ne pas compter sur le conteneur parent ne signifie pas que vous ne pouvez pas communiquer. Exposer une propriété dans le contrôle utilisateur que le parent va définir. Mais ayez une valeur par défaut pour qu’elle ne tombe pas en panne.

De plus, s’il s’agit d’un contrôle très spécifique, il n’ya aucune raison pour laquelle il serait mauvais de s’appuyer sur le parent. Ce n'est peut-être pas idéal, mais vous utiliseriez le contrôle utilisateur pour séparer le code.

Answer 2

Votre contrôle n'a pas besoin de savoir d'où proviennent ses données. Il n'a pas besoin de connaître la procédure stockée ni quoi que ce soit d'autre. Tout ce qu'il a besoin de savoir, ce sont les données qu'il doit montrer. Si je comprends bien votre contrôle, c'est une grille avec des filtres de date. Il recevra les données, les affichera et les filtrera par date. C’est très bien, il suffit de connaître les données à afficher et, peut-être, les dates de début et de fin par défaut du parent.

Answer 3

Si vous ne lui permettez pas de communiquer avec son parent, vous perdez le véritable pouvoir des contrôles utilisateur. Je pense que vous prenez peut-être un peu trop l’encapsulation dans ce cas.

Supposons que vous avez un contrôle utilisateur qui est simplement une table ou une vue en grille de différentes données utilisateur. Inévitablement, le contrôle de l'utilisateur devra connaître l'identificateur unique de l'utilisateur pour extraire ses données où qu'il se trouve, ce qui vous obligera bien sûr à créer une propriété publique que la page parente peut définir.

N'oubliez pas non plus qu'une action dans un contrôle utilisateur doit parfois déclencher une action sur le parent. Les délégués d’événement entrent en jeu ici, ils sont extrêmement utiles et, à mon avis, rendent les contrôles utilisateur encore plus utiles.

Supprimez simplement l’idée des contrôles utilisateur et des parents qui ne parlent pas, et vous trouverez les choses beaucoup plus faciles.

Answer 4

Ce contrôle utilisateur contient donc des éléments qui établiront une liaison de données avec un jeu de données renvoyé par la procédure stockée?

Voici un moyen de le gérer: Au lieu d'essayer de communiquer la procédure stockée au contrôle utilisateur, définissez l'ensemble de données sur lequel le contrôle utilisateur s'appuiera sur une propriété publique du contrôle utilisateur.

Au moment de l'exécution, votre code situé en dehors du contrôle utilisateur exécutera la procédure appropriée stockée et définira la propriété dataset de votre contrôle utilisateur sur le résultat renvoyé par le processus stocké.

Answer 5

Comme tout le monde l’a souligné, votre contrôle utilisateur doit disposer d’un moyen standard de communiquer ses intentions et son comportement. Cela ne signifie pas que vous devez avoir une référence au conteneur, et donc savoir ce que (MyPage.aspx) le contient réellement.

Ce que j’ai trouvé indispensable en travaillant avec les contrôles utilisateur, c’est les événements. Apprenez les événements et comment les utiliser. Les événements sont un excellent moyen de communiquer le comportement.

Dans votre exemple, je peux séparer vos critères (zones de texte de date) en son propre contrôle utilisateur. Créez une nouvelle classe qui hérite de EventArgs, qui contient vos critères (DateTime champs). Lorsque l'utilisateur clique sur Rechercher, déclenchez un événement (de type EventHandler<YourEventArgs>) avec votre personnalisation EventArgs. La page va gérer l'événement, interroger la base de données, puis transmettre les résultats à une méthode publique ou interne sur votre deuxième contrôle utilisateur, qui affiche les enregistrements.

La clé ici, votre contrôle de critères peut être réutilisé sur différentes pages si vous avez besoin d'appeler différentes procédures stockées. Pensez aux scénarios insertion vs mise à jour. Souvent, les éléments de l'interface utilisateur sont les mêmes. Vous pouvez créer un contrôle et l'utiliser sur deux pages différentes avec deux comportements différents (AddRecord.aspx et UpdateRecord.aspx). De plus, votre contrôle qui affiche les enregistrements est très facilement réutilisé.

Un des gros avantages est que vos pages et vos contrôles deviennent plutôt petits. Chaque contrôle / page ne concerne en réalité que son petit sous-ensemble de fonctionnalités. Votre code deviendra moins intimidant et plus facile à gérer.

Answer 6

  

& "Tell &"; le usercontrol quelle procédure stockée je voudrais exécuter

On dirait que vous cherchez des événements / des délégués
Demandez au contrôle d'exposer un événement et laissez le parent ajouter un gestionnaire (peut-être dans le constructeur, si vous souhaitez le forcer à ajouter un et un seul événement)

Vous pouvez également utiliser le modèle Commande / Stratégie. Le parent doit encapsuler la méthode et envoyer l'objet encapsulant au contrôle dans son constructeur.