Discussion :

[gadsweb]

Re-salut,

Alors là je deviens fou.
Je commence à maîtriser à peu près la portée des variables et des classes mais là je sèche.
J'ai une classe "Users" dans laquelle les méthodes font des requêtes sql pour obtenir des prénoms, des droits, etc..., avec comme paramètre un Id.
Elle est donc instanciée dans un formulaire A secondaire.

Comment dois-je faire pour récupérer les infos (noms, prénoms, etc...) dans un autre formulaire (principal par exemple) ou une autre classe, alors que le formulaire A de création a été fermé ? En gros, à partir du moment où j'ai effectué les requêtes et donc obtenu les infos de l'utilisateur, je ne voudrais pas avoir à refaire les requêtes à chaque fois que j'ai besoin de ces infos.

Dois-je instancier ailleurs et où ou alors comment faire ?


Merci

[katkiller]

Salut,

Il faut ré instancier ta classe dans ton autre classe ou faire une classe mère commune à tes deux classes. Par contre pour éviter de refaire les requêtes il faudra mettre en place un système de cache.

[phil_tema]

Salut !

Si je comprend bien le problème :

Ta classe Users doit contenir des infos obtenues par request SQL, qui serviront plusieurs fois. Je vois là un soupçon de
variables globales...

Perso, je crée souvent un "Data Manager" dans mes applis, dans lequel je stocke tout ce qui est susceptible d'être utilisé
plusieurs fois, à des endroits et moments différents. La précaution à prendre est qu'il soit Thread Safe
(voir ici : http://jlambert.developpez.com/tutor...gleton-csharp/)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
public sealed class DataManager
{
    private static readonly Lazy<DataManager> lazy =
        new Lazy<DataManager>(() => new DataManager());
 
    public static DataManager Instance { get { return lazy.Value; } }
 
    // constructor
    private DataManager()
    {
    }
 
    public string FileName
    {
    get; set;
    }
}

de n'importe quel endroit tu peux accéder à la propriété FileName par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DataManager.Instance.FileName = "toto.exe"

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

string FileStr = DataManager.Instance.FileName

Hope this helps !

Phil

[gadsweb]

Ben oui c'est un peu çà, une variable globale.
Mais comme je crois savoir que ce n'est pas une bonne pratique, je ne sais pas comment faire.
Je pensais qu'un objet instancié serait utilisable un peu partout dans l'appli, je pense que c'est plus efficace que de refaire les requêtes, etc...

Pour être un peu plus précis, j'ai un formulaire de login/password qui une fois l'utilisateur connecté, va chercher plusieurs infos sur une base de données qui peut être assez grosse. En voulant optimiser, je me dis que je fais mes requêtes une fois pour toutes et j'utilise les infos alors stockées quand j'en ai besoin.

Dans ce cas, l'autre solution consisterait à effectuer ma requête à chaque fois que j'ai besoin de l'info. Ca me semble bizarre que ce soit mieux de cette manière.

Mais alors, pour avoir une confirmation sur un point. Tout objet instancié dans une classe A ne sera jamais disponible dans une classe B ? Donc on ne peut pas avoir un objet utilisable dans des formulaires ou classes distincts ? C'est bien ça ?

[rv26t]

Bonjour,

Mais alors, pour avoir une confirmation sur un point. Tout objet instancié dans une classe A ne sera jamais disponible dans une classe B ? Donc on ne peut pas avoir un objet utilisable dans des formulaires ou classes distincts ? C'est bien ça ?

Pour récupérer les info de ta classe depuis un formulaire A secondaire.
Une solution parmi d'autres.
Tu crées un constructeur dans ton formulaire A qui reçoit en paramètre par référence une variable du type de ta classe. ("Users" dans ton cas)
Ainsi tu peux appeler ton formulaire depuis n'importe quel endroit de ton code et il ne dépend d'aucun autre formulaire ou classe perso.
La classe Users est instanciée dans un autre formulaire (principal par exemple) et passé en param au formulaire A, ensuite, à la fermeture du formulaire A tu peux l'utiliser dans l'autre formulaire (ou classe).

[gadsweb]

Merci pour ces infos.
Mais, si je comprends bien cette façon de faire (et c'est pas sûr :-)), à chaque fois que dans un formulaire j'aurai besoin des infos relatives à "Users", je devrai instancier et donc rééxecuter mes requêtes ?

Ce que je tente mais je ne sais pas si c'est propre.
Dans ma classe "Users", je crée une méthode "Create" avec comme paramètre un id utilisateur qui exécute les requêtes et renvoie le résultat dans une variable public static. Ensuite, n'importe où dans l'appli (au début de préférence), j’exécute la méthode Create, ce qui fait qu'ensuite, de n'importe où, j'accède au nom par exemple en faisant Users.Nom.
Est-ce correct et propre ?

[rv26t]

Merci pour ces infos.
Mais, si je comprends bien cette façon de faire (et c'est pas sûr :-)), à chaque fois que dans un formulaire j'aurai besoin des infos relatives à "Users", je devrai instancier et donc rééxecuter mes requêtes ?

Effectivement, ou bien tu crés un contexte de travail qui contiendra tes données, et que tu utiliseras de partout.

Ce que je tente mais je ne sais pas si c'est propre.
Dans ma classe "Users", je crée une méthode "Create" avec comme paramètre un id utilisateur qui exécute les requêtes et renvoie le résultat dans une variable public static. Ensuite, n'importe où dans l'appli (au début de préférence), j’exécute la méthode Create, ce qui fait qu'ensuite, de n'importe où, j'accède au nom par exemple en faisant Users.Nom.
Est-ce correct et propre ?

L'utilisation de static (perso j'évite) est pratique pour ce genre de problème, il ne faut bien sur pas en abuser et tout mettre en static.
Après placer les variables static dans chaque classe qui en a besoin ou les regrouper au sein d'un contexte de travail applicatif, c'est un choix à faire.
Je ferai plutôt le choix du contexte applicatif, ainsi en cas de réutilisation des classes dans d'autres projets, il n'y a pas (éventuellement) de variable static non utilisées. Les variables communes applicatives sont ainsi regroupées et les accès à celles-ci situé dans une même entité. [Edit](pratique avec l'intellisense)[/Edit] Mais c'est un choix personnel.

Voici comment je procède, (juste pour exemple) je cré une classe contexte de travail applicatif, contexte qui référence mes données nécessaires à l'application.
Ensuite mon contexte contient les propriétés dont l'application a besoin, ce qui correspond à ton utilisation en static mais plus dans le sens objet à mon gout. Je passe en paramètre ref cette instance de contexte.
En utilisant static, il n'y a effectivement plus besoin de passer en paramètre. C'est un choix.
Donc dans mon cas, la classe user n'a pas à connaitre cette classe contexte. Elle est instanciée au moment ou l'on en a besoin, renvoie les données à l'appelant qui les stocke et est détruite. Elle pourra être réutilisé plus tard si nécessaire. (l'appelant stocke les données pour une courte durée ou la durée de l'application)
Je peux aussi instancier des classes dans mon contexte qui pourront être utilisées dans plusieurs form, et les détruire lorsque je n'en ai plus besoin.
[Edit]Autre avantage avec une classe contexte, on peut créer plusieurs contexte de travail au sein d'un même applicatif, à l'image des sessions windows. (Impossible si on a des variables static)[/Edit]
Enfin ceci n'est qu'une façon de faire que j'utilise.

J'espère que nous verrons d'autres approches et avis.

[gadsweb]

Merci pour toutes ces infos.