2008-09-27 8 views
6

J'écris actuellement une interface pour permettre aux applications d'envoyer des données d'exception à un référentiel central à des fins de support. Je suis à une situation embarrassante sur la façon de transmettre des données supplémentaires contextuelles:IDictionary <string, string> ou NameValueCollection

public interface IExceptionNotifier 
{ 
    void Notify(Exception ex, NameValueCollection context); //this  
    void Notify(Exception ex, IDictionary<string, string> context); //or this 
} 

Je me suis souvent trouvé est une position similaire lors de la création lookups. Ignorer si le concept du notificateur d'exception est bon, est-il préférable d'utiliser un IDictionary<string, string> ou un NameValueCollection? Pourquoi choisiriez-vous l'un par rapport à l'autre?

Répondre

1

Si le contexte est une valeur jetable et (la partie importante vient ici) ne sera pas sérialisé, par ex. pour envoyer les données à un autre système, j'irais avec l'IDictionary car cela rend l'utilisation de votre interface plus flexible.

Si, en revanche, le contexte est conservé tout le temps ou que le contexte sera sérialisé, utilisez NameValueCollection car vous contrôlez alors ce que vous obtiendrez de votre appelant.

Editer: mausch a raison d'utiliser une approche générique, mais je n'utiliserais toujours pas d'interface si vous voulez sérialiser les données.

+0

Pourriez-vous développer «sous le contrôle de ce que vous obtiendrez réellement de votre interlocuteur»? La possibilité d'un appelant d'envoyer des clés en double est-elle le problème? Je suppose que je ne comprends pas très bien pourquoi vous évitez un dictionnaire si la sérialisation est en cause. –

+1

@JeffBridgman: C'était il y a près de dix ans, je ne me souviens pas de ce que je voulais dire;) Je suppose qu'il s'agit d'obtenir un objet d'une classe spécifique (ie avec certaines contraintes comme le support de sérialisation), ou d'obtenir * une certaine interface. Par exemple, l'implémentation IDictionary peut ne pas prendre en charge la sérialisation ou certaines méthodes, tandis que NameValueCollection est une implémentation fixe, elle dépend donc de ce que vous voulez faire avec le contexte. Notez qu'il y a plusieurs autres questions à ce sujet sur SO avec des discussions intéressantes. – OregonGhost

5

(En supposant .NET 3.5 ici. Pre .NET 3.5, NameValueCollection aurait l'avantage d'être en mesure de lier plusieurs valeurs à une clé, sans équivalent direct dans les collections « normales ».)

Voulez-vous clés pour avoir des valeurs potentiellement multiples? Si oui, je considérerais ILookup < TKey, TValue>. Sinon, j'irais pour IDictionary < TKey, TValue>. Mis à part toute autre chose, si le récepteur veut faire un traitement où LINQ leur serait utile, l'une ou l'autre des interfaces génériques sera plus belle que NameValuePair. De même, il peut être plus facile pour l'appelant de produire un dictionnaire/une recherche en utilisant LINQ s'il a déjà un type de contexte générique ou dynamique.

Questions connexes