none
Variable globale RRS feed

  • Question

  • Bonjour tout le monde,

    Ayant oublié au juste la syntaxe pour déclarer une variable globale (c'est-à-dire déclarée une bonne fois pour toutes et accessible depuis tout le projet) j'ai mené une recherche sur Internet et j'ai vu que presque tout le monde conseille de créer une classe static et mettre ses variables globales dedans, en les préfixant du nom de la variable static au moment de l'appel.

    Y a-t-il un avantage à procéder ainsi, par rapport à mettre ceci dans le Global.asax ?

        public static string gstrCultureDefault;
        
        void Application_Start(object sender, EventArgs e) 
        {
            gstrCultureDefault = "fr";
        }

    D'ailleurs, dans l'exemple que je donne je ne souhaite pas que la variable puisse être modifiée en cours d'exécution, donc je ne mets rien dans Application_Start, et je remplace la première ligne par :

        public static readonly string gstrCultureDefault = "fr";

    J'ai cherché à mettre const, mais non, l'intellisense n'avait pas l'air d'en vouloir.

    vendredi 6 juin 2014 08:41

Réponses

  • Alors j'ai progressé un peu depuis tout-à-l'heure sur l'utilisation des variables globales, et je me suis rendu compte que global.asax est exécuté au chargement de la première page : il n'est donc pas reconnu dans les classes du répertoire Asp_Code.

    Celles-ci doivent donc comporter une variable public à initialiser depuis l'extérieur. ça peut avoir un sens si on est plusieurs à travailler sur le projet, de les initialiser depuis le global.asax si il n'y a pas une classe plus évidente qu'une autre pour contenir les variables globales, puisque le global.asax, il n'y en a qu'un.

    On peut alors avoir :

        void Application_Start(object sender, EventArgs e)
        {
            Cult.strCultureDefault = ASP.global_asax.gstrCultureDefault;
        }

    Et si on a besoin de l'objet Request, du coup on ira voir dans le Page_Load de la (ou des) page(s) maîtresse(s).

    Après bien sûr l'essentiel est de se mettre d'accord dans l'équipe, surtout que j'ai un peu l'air de me raccrocher aux branches :)

    A propos du Singleton, justement je me suis posé la question, tout-à-l'heure, de son avantage par rapport aux propriétés static. Grosso modo, c'est le même but ? Peut-être que ça représente des notions différentes dans l'environnement métier ?

    Après, simple c'est bien, mais je vais quand même creuser un peu les Design Patterns : déjà que je vais bricoler en xml pour accéder aux ressources, si en plus il faut tout changer le jour où on change de base de données ça va être moins simple :)

    En tout cas merci pour cet éclairage.

    ______________________________________

    Voilà un élément de réponse pour le choix entre Singleton et méthodes statiques : dans une méthode statique, on ne peut pas déclarer de tableau.

    • Modifié Gloops vendredi 6 juin 2014 16:10
    • Marqué comme réponse Aurel Bera mardi 10 juin 2014 05:00
    vendredi 6 juin 2014 14:27

Toutes les réponses

  • Bonjour,

    Non, il n'y a pas de vrai avantage dans votre cas ^^.

    Il faut réaliser qu'en informatique s'affronte souvent des puristes face à des gens pragmatiques... C'est ainsi qu'ASP.NET vs ASP.NET MVC fait couler de l'encre commme Struts, JSF côté Java versus JSP/Servlet, ASP.NET, PHP; etc.

    L'avantage d'une classe statique avec des variables statiques est de regrouper en un point toute les définitions  statiques et de simplifier leur appel au niveau des classes dans l'application web/couches business.

    Sachez en outre que ceux qui préconisent la classe static oublient également des concepts.. Que vaut une classe static vis-à-vis d'un singleton (pattern GOF) ? Que vaut-il mieux ? Quel impact sur les problématiques de threading, constructeurs, etc, etc.

    Je ne veux pas vous embrouiller, mais simplement vos dire qu'il n'y a pas une bonne façon de faire mais plusieurs ; chacune avec leurs avantages et inconvénients.

    J'ai envie de vous dire "tout dépend de l'usage" ! Si gsrCultureDefault n'est utilisé que dans votre Global.asax alors oui, c'est suffisant. Si vous l'utilisez ailleurs ou le partagez avec des classes métiers (en gros, si vous prévoyez de rendre votre code accessible pour du code non ASP.NET comme WPF ou WinForm), non, il vaut mieux une classe statique.... Ou bien d'autres pattern, comme variables applicatives, cache, etc !! Il y a tellement de cas.

    Les méthodologies de développement modernes prônent l'utilisation de ce qui est "agile". En d'autres termes, s'adapter au besoin, faire du refactoring si nécessaire. Un architecte pur et dur, vous dirait classe static dans tous les cas alors qu'un architecte agile vous dirait, Global.asax si c'est plus simple, colle au besoin et satisfait le cas d'utilisation ; ce qui semble être votre cas !

    Ne craignez jamais de faire les choses simplement ; on appelle cela du KISS (Keep It Simple Stupid). Ne rajoutez de la complexité que si c'est strictement nécessaire ; vous verrez, votre code gagnera en lisibilité et maintenance ^^

    Bien cordialement,

    Fabrice JEAN-FRANCOIS

    vendredi 6 juin 2014 13:16
  • Alors j'ai progressé un peu depuis tout-à-l'heure sur l'utilisation des variables globales, et je me suis rendu compte que global.asax est exécuté au chargement de la première page : il n'est donc pas reconnu dans les classes du répertoire Asp_Code.

    Celles-ci doivent donc comporter une variable public à initialiser depuis l'extérieur. ça peut avoir un sens si on est plusieurs à travailler sur le projet, de les initialiser depuis le global.asax si il n'y a pas une classe plus évidente qu'une autre pour contenir les variables globales, puisque le global.asax, il n'y en a qu'un.

    On peut alors avoir :

        void Application_Start(object sender, EventArgs e)
        {
            Cult.strCultureDefault = ASP.global_asax.gstrCultureDefault;
        }

    Et si on a besoin de l'objet Request, du coup on ira voir dans le Page_Load de la (ou des) page(s) maîtresse(s).

    Après bien sûr l'essentiel est de se mettre d'accord dans l'équipe, surtout que j'ai un peu l'air de me raccrocher aux branches :)

    A propos du Singleton, justement je me suis posé la question, tout-à-l'heure, de son avantage par rapport aux propriétés static. Grosso modo, c'est le même but ? Peut-être que ça représente des notions différentes dans l'environnement métier ?

    Après, simple c'est bien, mais je vais quand même creuser un peu les Design Patterns : déjà que je vais bricoler en xml pour accéder aux ressources, si en plus il faut tout changer le jour où on change de base de données ça va être moins simple :)

    En tout cas merci pour cet éclairage.

    ______________________________________

    Voilà un élément de réponse pour le choix entre Singleton et méthodes statiques : dans une méthode statique, on ne peut pas déclarer de tableau.

    • Modifié Gloops vendredi 6 juin 2014 16:10
    • Marqué comme réponse Aurel Bera mardi 10 juin 2014 05:00
    vendredi 6 juin 2014 14:27