Singleton vs Static Class pour exposer les données lues à partir de xml

Nous avons un fichier xml PageRoles qui contient le chemin de la page et le rôle de l'utilisateur qui peut accéder à cette page.Singleton vs Static Class pour exposer les données lues à partir de xml

Nous maintenons un dictionnaire dans une classe statique, qui obtient le constructeur statique int chargé pour la classe. La classe a une méthode CheckIfRoleAllowed qui prend un chemin de page et retourne un booléen.

Chaque page appelle CheckIfRoleAllowed à la page Init.

static class PageAccessChecker 
{ 
static Dictionary<string, UserRoleType[]> _PageAccessPermissions; 
static FileSystemWatcher _XmlWatcher; 

static PageAccessChecker() 
{ 
    // Load page access permissions from xml 
    // Set FileSystemWatcher watcher to watch for changes 
} 

public static CheckIfRoleAllowed(string pagePath) 
{ 
} 

}

Serions-nous mieux de le faire en utilisant le modèle singleton? Si oui, pourquoi?

Cordialement.

Source

2008-12-02 SharePoint Newbie

L'un ou l'autre va coupler étroitement les classes dépendantes à cette classe. Demandez-vous, "comment vais-je tester unitairement une classe ou une méthode qui dépend d'un PageAccessChecker indépendamment de PageAccessChecker?" @ James Curran est correct. – TrueWill

Vous utilisez un singleton. Simplement, il y a 2 implémentations habituelles pour les singletons, l'autre étant l'instanciation de la classe et ayant un membre statique référençant cette instance.

Votre mise en œuvre rend les appels plus simples OMI:

PageAccessChecker.CheckIfRoleAllowed(path);

au lieu de:

PageAccessChecker._default.CheckIfRoleAllowed(path);

Source

2008-12-02 07:31:34

Je vois deux avantages d'utiliser le motif de singleton (si elle est appliquée à travers, par exemple, une propriété statique): Vous pouvez retarder le chargement du fichier XML jusqu'à ce que vous accédiez à la première page.

Vous pouvez vérifier si le fichier XML a été modifié sur le disque et le recharger automatiquement lors de l'accès suivant.

Un inconvénient pourrait être que vous devez rendre l'accès thread-safe en utilisant un verrou.

Source

2008-12-02 07:33:49

En fait, le fichier est chargé en appelant une méthode de chargement à partir du constructeur. Lorsque le fichier change, la méthode Changed de FileSystemWatcher appelle également la même méthode. –

Hourra pour FileSystemWatcher - J'étais sur le point de suggérer le contraire – annakata

En fait, vous ne voulez vraiment pas un singleton ou une classe statique. Tout d'abord, une classe statique est un singleton. Je suppose que ce que vous demandez vraiment est "Est-ce un avantage d'ajouter le rigmarole pour s'assurer que la menace est sûre et qu'il n'existe qu'un seul, ou en d'autres termes, ai-je besoin d'un singleton 'spécial'?" Pour lequel la réponse est "Non", puisque vous ne voulez pas un singleton.

Un singleton est destiné aux objets dont peut être un seul, pas pour les objets dont un seul est nécessaire. Ce n'est pas le cas ici. Il n'y a rien dans cette situation qui appelle un singleton. Ce que vous voulez réellement est une chose appelée "variable globale".

"Mais, attendez !!!" vous dites. "Les variables globales ne sont-elles pas mauvaises?" Eh bien, oui, il y en a. Mais ce n'est pas pertinent ici. Que vous l'appeliez une classe statique ou un singleton ou quoi que ce soit, ce que vous avez réellement ici est une variable globale. L'appeler autrement ne changera rien.

Source

2008-12-02 08:04:25

Ce n'est pas si simple: que GlobalVar va être un type de classe, donc vous * cherchez * un singleton en implémentation, et imho beaucoup mieux d'adresser cela avec une interface pont qu'avec une référence globale réelle – annakata

@annakata: quelle est la différence? Vous obtenez une référence globale de toute façon. – orip

@Annakata: Je n'ai jamais dit ça. Ce devrait être un objet d'instance de classe. Comme je l'ai dit, ce n'est pas parce qu'il n'en a besoin que d'une que l'implémentation ne peut en autoriser plus d'une. –

-1

Si vous conservez le constructeur de classe privé, il n'y a pas de réelle différence - ce sont deux variables globales qui peuvent être paresseusement initialisées.

Si vous conservez le constructeur de classe public ou protégé et utilisez uniquement le modèle pour créer un global (pour ne pas appliquer une instance unique), vous pouvez au moins tester votre classe singleton. Mais ce que vous devriez vraiment essayer est d'éviter les singletons et d'utiliser l'injection de dépendance à la place. Voir Singletons are Pathological Liars par Miško Hevery.

Source

2008-12-02 08:08:09 orip

downvoted, mais c'est toujours vrai :-) – orip

Singleton vs Static Class pour exposer les données lues à partir de xml

Répondre

Questions connexes