C# Fonctionnalité utilitaire Méthode statique/Classe statique/Modèle singleton

Question

Je crée une méthode utilitaire GetServiceTicketNumber() à l'intérieur d'une classe utilitaire, puisque la méthode sera utilisée souvent je ne veux pas instancier à chaque fois donc j'ai fait la méthode & _ticket comme statique.

UtilityManager contient également plusieurs autres méthodes.

Ma question est:

1) Est-ce la bonne façon de mettre en œuvre la fonctionnalité? 2) si faire UtilityManager aussi une classe statique/non ?, quelle différence cela fait-il?

3) Si le code ci-dessous (pour la fonctionnalité TicketProvider) est écrit en modèle singleton? (Compte tenu de la plupart de la classe singleton instancier la même classe UtilityManager.)

autres informations: classe appelée dans Asp.Net application

public sealed class UtilityManager 
{  
    public static readonly TicketProvider _ticket = new TicketProvider(); 

    public static int GetServiceTicketNumber() 
    {  
     return _ticket.GetTicket(); 
    } 
} 

Answer 1

méthodes d'utilité sont mieux déclarées outils statiques et beaucoup de vérificateur de code comme StyleCop sera effectivement recommande que vos fonctions d'utilité soient statiques, de sorte que vous soyez sur la bonne voie. Si vous voulez avoir une instance singleton du TicketProvider, vous pouvez utiliser un constructeur statique pour vous assurer que le champ est initialisé avant qu'il ne soit accédé et initialisé qu'une seule fois. Vous pouvez également rendre la classe statique pour indiquer que cette classe n'est pas conçue pour être instanciée, mais uniquement pour l'utilisation de l'utilitaire. Voici ma recommandation:

public static class UtilityManager 
{ 
    static UtilityManager() 
    { 
     Ticket = new TicketProvider(); 
    } 

    public static TicketProvider Ticket { get; private set; } 

    public static int GetServiceTicketNumber() 
    {  
     return Ticket.GetTicket(); 
    } 
} 

Answer 2

1: semble viable; c'est souvent un appel subjectif; Par exemple, si votre utilitaire repose sur des champs statiques, cela vous limite à une seule installation par AppDomain. Cela peut être bien, mais peut être limitant si vous passez plus tard à la multi-location. Il peut également être plus difficile à tester. 2: une classe statique ne peut pas avoir des instances (ou des méthodes d'instance); si les méthodes sont toutes implémentées comme statiques alors probablement cela devrait être une classe statique

3: Je ne vois aucun avantage dans le singleton par rapport à statique ici. Un singleton est utile si vous avez besoin de traiter comme une instance, par exemple pour implémenter une interface.

Un autre choix ici pourrait être une instance régulière, mais assurez-vous que tout votre code parle à la même instance - peut-être via IoC/DI (et peut-être pas). Cela vous donnera une commodité similaire, mais plus de souplesse pour tester et multi-location

En note, vous pouvez également considérer les implications threading, en particulier dans une application web (très threaded). Les données partagées (y compris les champs statiques et les instances partagées) doivent être correctement synchronisées (ou immuables).