Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre habitué Avatar de goute
    Homme Profil pro
    Développeur éclectique
    Inscrit en
    novembre 2008
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur éclectique
    Secteur : Finance

    Informations forums :
    Inscription : novembre 2008
    Messages : 224
    Points : 159
    Points
    159

    Par défaut Buisness Layer (.Net) - Méhodes statiques vs instances

    Bonjour,

    Voici un sujet ou je ne trouve pas de consensus.

    J'ai pour habitude de mettre les méthodes de mes BLL en statique est ce une bonne pratique ? est ce plutôt déconseillé ?

    Jusqu’à aujourd'hui cela ne m'a pas posé de problèmes, mais on m'a fortement conseillé de mettre cette couche en singleton au cas ou on avait besoin de stocker des données dans cette couche.

    En gros, sans vouloir vous polluer avec mes spécificités, les méthodes au sein d'une BLL doivent elles être statique ou non ?

    Merci pour vos réponses

    Bonne journée,

    Goute
    Moins tu vas vite, plus tu vas moins vite!

  2. #2
    Membre confirmé
    Profil pro
    Inscrit en
    juin 2002
    Messages
    332
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : juin 2002
    Messages : 332
    Points : 493
    Points
    493

    Par défaut

    Personnellement, j'évite les méthodes statiques, quelle que soit le layer.

    Pourquoi? Je préfère une approche plus strictement orientée-objet car cela me permet de mieux bénéficier de stratégies de développement qui ne commencent à être bénéfiques que lorsqu'un système dépasse une certaine masse critique ou un certain niveau de complexité. Par exemple, j'utilise la composition plutôt que l'héritage et donc les interfaces afin de bénéficier des avantages de l'inversion de contrôle. Une méthode statique ne peut faire partie d'une interface.

    Voici une réponse à laquelle je me réfère concernant cette question qu'on me pose régulièrement.

    http://stackoverflow.com/questions/2...ses-in-c-sharp

  3. #3
    Membre habitué Avatar de goute
    Homme Profil pro
    Développeur éclectique
    Inscrit en
    novembre 2008
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur éclectique
    Secteur : Finance

    Informations forums :
    Inscription : novembre 2008
    Messages : 224
    Points : 159
    Points
    159

    Par défaut

    Merci pour cette réponse !
    Moins tu vas vite, plus tu vas moins vite!

  4. #4
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 925
    Points
    2 925

    Par défaut

    Citation Envoyé par goute Voir le message
    mais on m'a fortement conseillé de mettre cette couche en singleton au cas ou on avait besoin de stocker des données dans cette couche.

    • D'abord "mettre une couche en singleton" est assez douteux, on peut limiter une classe à une seule instance dans un cadre donné mais une couche... ?

    • Ensuite le but d'une couche business n'est pas de stocker des données et quand bien même, je ne vois pas le rapport avec Singleton.

    • Enfin, Singleton est considéré par toute une partie de la communauté comme un anti-pattern depuis plusieurs années, car si on l'utilise comme c'est préconisé dans la majorité de la littérature sur les patterns, c'est une dépendance implicite qu'on sort de son chapeau au milieu de l'exécution d'une méthode. Cela rend cette méthode et son objet peu testable et fortement couplé à ce singleton. L'idée est plutôt d'utiliser des dépendances explicites qu'on passe à l'objet consommateur (via le constructeur, des propriétés ou des paramètres de méthodes).


    Sur la question des méthodes statiques ou non, je suis plutôt d'accord avec Babyneedle en rajoutant que la testabilité est aussi un point faible des méthodes statiques puisqu'on ne peut pas facilement bouchonner ou mocker un appel à une méthode statique dans un test.

    Un petit bémol mais c'est plutôt pour l'anecdote : dans le monde de la programmation fonctionnelle, toute fonction peut s'apparenter à une méthode statique puisqu'elle est censée être référentiellement transparente (pas de side effect, pas de modification d'état). D'ailleurs des compilateurs de langages fonctionnels comme F# traduisent leurs fonctions en des méthodes .NET statiques dans l'IL généré. Ces fonctions ne souffrent pas des défauts des méthodes statiques citées précédemment car, via sa signature, on peut manipuler MaFonction comme un type à part entière qu'on peut passer en paramètre d'autres fonctions, utiliser en valeur de retour d'une fonction... chose qui n'est pas faisable en orienté objet classique avec MaClasseStatique.MaFonction qui n'est pas désignable de façon abstraite.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [VB.NET]une seule instance par fenetre MDI
    Par pat59 dans le forum Windows Forms
    Réponses: 2
    Dernier message: 20/02/2006, 11h14
  2. [VB.NET] Classes et instances
    Par Bz dans le forum ASP.NET
    Réponses: 6
    Dernier message: 16/02/2006, 09h46
  3. Réponses: 10
    Dernier message: 16/12/2005, 10h17
  4. [VB.NET]Créer une instance par page
    Par Dnx dans le forum ASP.NET
    Réponses: 20
    Dernier message: 31/10/2005, 13h22
  5. [VB.NET] WebUserControl : instance et property
    Par lord_paco dans le forum ASP.NET
    Réponses: 3
    Dernier message: 20/05/2004, 12h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo