J'ai été développeur Web depuis un certain temps en utilisant désormais ASP.NET et C #, je veux essayer d'accroître mes compétences en utilisant les meilleures pratiques.
J'ai un site web. Je veux charger les paramètres une fois éteint et je suffisez-la simplement où j'en ai besoin. J'ai donc fait des recherches et 50% des développeurs semblent utiliser le modèle singleton pour le faire. Et les 50% des 50% des développeurs sont Ant-Singleton. Ils détestent tous des singletons. Ils recommandent une injection de dépendance.
Pourquoi les singletons sont-ils mauvais? Quelle est la meilleure pratique pour charger les paramètres de sites Web? Devraient-ils être chargés une seule fois et référencés si nécessaire? Comment pourrais-je faire cela avec une injection de dépendance (je suis nouveau à cela)? Y a-t-il des échantillons que quelqu'un pourrait recommander pour mon scénario? Et j'aimerais aussi voir un code de test unitaire pour cela (pour mon scénario).
merci Brendan
4 Réponses :
Il y a une bonne discussion sur les modèles de singleton et des exemples de codage ici ... http: // fr. wikipedia.org/wiki/singleton_pattern Voir aussi ... http: //fr.wikipedia .org / wiki / dépendance_injection
Pour une raison quelconque, les singletons semblent diviser les programmeurs dans des professionnels puissants et des anti-camps. Quels que soient les mérites de l'approche, si vos collègues sont contre cela, il est probablement préférable de ne pas en utiliser un. Si vous êtes seul, essayez-le et voyez.
Je veux aussi le tester, mais je n'ai aucune idée de l'unité tester un modèle singleton?
Généralement, j'évite les singletons car ils rendent plus difficiles à tester votre application. Les singletons sont difficiles à maigrir pour des tests d'unités précisément en raison de leur nature - vous obtenez toujours le même, et non celui que vous pouvez configurer facilement pour un test unitaire. Données de configuration - Données de configuration fortement typées, de toute façon - est une exception que je fais, cependant. Typiquement les données de configuration sont relativement statiques de toute façon et l'alternative implique de rédiger une belle quantité de code pour éviter les classes statiques Le framework permet d'accéder à la web.config de toute façon.
Il y a quelques façons différentes de l'utiliser qui permettra toujours d'utiliser Vous devez tester votre application. Une façon (peut-être que les deux manières, si votre singleton ne lit pas paresseusement l'app.cofnig) est d'avoir un fichier app.config par défaut dans votre projet de test d'unité fournissant les valeurs par défaut requises pour vos tests. Vous pouvez utiliser la réflexion pour remplacer toutes les valeurs spécifiques nécessaires dans vos tests d'unités. En règle générale, je configurerais une méthode privée permettant de supprimer l'instance de singleton privé d'être supprimée dans le test configuré si je fais des modifications pour des tests particuliers. P>
Une autre solution est de ne pas utiliser le singleton directement, mais Créez une interface pour que la classe Singleton implémente. Vous pouvez utiliser une injection de main de l'interface, par défaut de l'instance Singleton si la valeur fournie est NULL. Cela vous permet de créer une instance fausse que vous pouvez passer à la classe sous test pour vos tests, mais dans votre code réel, utilisez l'instance Singleton. Essentiellement, chaque classe qui a besoin qu'il maintient une référence privée à l'instance Singleton et l'utilise. J'aime bien cela un peu mieux, mais puisque le singleton sera créé, vous aurez peut-être toujours besoin du fichier APP.Config par défaut, à moins que toutes les valeurs soient chargées paresseusement. P>
public class Foo
{
private IAppConfiguration Configuration { get; set; }
public Foo() : this(null) { }
public Foo( IAppConfiguration config )
{
this.Configuration = config ?? AppConfiguration.Instance;
}
public void Bar()
{
var value = this.Config.SomeMaximum;
...
}
}
Désolé si tard. Commentaires intéressants sur les données de configuration comme une exception. Je prends généralement l'approche opposée. J'essaie d'implémenter ma configuration d'exécution en tant qu'interfaces et les injecter à l'application au démarrage. De cette façon, mon programme dépend uniquement des interfaces elles-mêmes qui sont libres de changer ou de se moquer de test. Au démarrage, j'ai besoin de lire des objets à l'aide de ConfigurationManager, mais c'est le seul endroit qui est au courant de cette classe statique.
C'est l'approche que j'ai migrée également, bien que mon interface de configuration soit enregistrée comme un singleton dans mon conteneur DI pour le meilleur des deux mondes. Il s'agit toujours du seul exemple d'une implémentation singleton que je me sens à l'aise, cependant.
Les modèles de conception peuvent être des choses incroyables. Malheureusement, le singleton semble coller comme un pouce douloureux et peut être considéré comme un anti-motif (il favorise les mauvaises pratiques). Bizary, la majorité des développeurs ne sauront que un modèle de design, et c'est le singleton.
Idéalement, vos paramètres doivent être une variable de membre dans un emplacement de haut niveau, par exemple l'objet d'application qui possède les pages Web que vous reprochez. Les pages peuvent ensuite demander à l'application pour les paramètres ou que l'application peut transmettre les paramètres car les pages sont construites.
Dans le cours des modèles de conception, j'ai assisté, le singleton était le premier enseigné. Cela pourrait être la raison pour laquelle tout le monde s'en souvient.
@Brian: Et ce modèle est décrit à Sites.google.com/site/steveveyegge2 / singleton-considéré comme stupi d
Avez-vous un échantillon de code de ce que vous avez décrit? Ou un lien?
Vous pourrez peut-être utiliser quelque chose comme décrit ici: support.microsoft.com/kb/309018
Un moyen d'aborder ce problème, c'est de le fouetter comme un problème Quelle que soit la classe / la page Web, etc. Il faut utiliser les paramètres de configuration devrait déclarer une dépendance sur un iconfigsettagesService (usine / référentiel / quoi que ce soit - vous-aimez-les-appel). p> de sorte que votre classe obtiendrait des paramètres comme celui-ci: P> ConfigSettings _configSettings = _configSettingsService.GetTheOnlySettings();
duplicailler possible de Existe-t-il des alternatives viables au Gof Singleton Modèle?