Discussion :

[goute]

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

[Babyneedle]

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

[goute]

Merci pour cette réponse !

[Luckyluke34]

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.