IDictionary <строка, строка> или NameValueCollection
В настоящее время я пишу интерфейс, позволяющий приложениям отправлять данные об исключениях в центральный репозиторий в целях поддержки. Я не понимаю, как передавать дополнительные контекстные данные:
public interface IExceptionNotifier
{
void Notify(Exception ex, NameValueCollection context); //this
void Notify(Exception ex, IDictionary<string, string> context); //or this
}
Я часто сталкивался с подобной позицией при создании справочников. Не обращая внимания на то, хороша ли концепция уведомления об исключениях, лучше ли использовать IDictionary<string, string> или NameValueCollection? Почему вы предпочли бы одно другому?
Ответы 2
Если контекст представляет собой выбрасываемое значение и (здесь важная часть) не будет сериализован, например для отправки данных в другую систему я бы выбрал IDictionary, потому что он делает использование вашего интерфейса более гибким.
Если, с другой стороны, контекст сохраняется все время или контекст будет сериализован, используйте NameValueCollection, потому что тогда вы находитесь под контролем того, что вы фактически получите от вызывающего абонента.
Обновлено: mausch прав в том, что вы должны использовать общий подход, но я все равно не буду использовать интерфейс, если вы хотите сериализовать данные.
@JeffBridgman: Это было почти десять лет назад, на самом деле я не помню, что имел в виду;) Думаю, речь идет о получении объекта определенного класса (т.е. с определенными ограничениями, такими как поддержка сериализации) или о получении что-нибудь с определенным интерфейсом. Например, реализация IDictionary может просто не поддерживать сериализацию или некоторые методы, в то время как NameValueCollection является фиксированной реализацией, поэтому это зависит от того, что вы хотите делать с контекстом. Обратите внимание, что есть еще несколько вопросов об этом по SO с интересными обсуждениями.
(Предполагая, что здесь .NET 3.5. До .NET 3.5, NameValueCollection имела преимущество, заключающееся в возможности связывать несколько значений с ключом, без прямого эквивалента в «обычных» коллекциях.)
Вы хотите, чтобы ключи имели потенциально несколько значений? Если это так, я бы рассмотрел ILookup <TKey, TValue>. В противном случае я бы выбрал IDictionary <TKey, TValue>.
Помимо всего прочего, если получатель хочет выполнить какую-либо обработку, в которой LINQ был бы ему полезен, любой из универсальных интерфейсов будет лучше, чем NameValuePair. Точно так же вызывающему абоненту может быть проще создать словарь / поиск с помощью LINQ, если у него уже есть общий или динамический вид контекста.
Не могли бы вы расширить понятие «под контролем того, что вы действительно получите от вызывающего абонента»? Проблема в том, что звонящий отправляет повторяющиеся ключи? Думаю, я не совсем понимаю, почему вам следует избегать словаря, если речь идет о сериализации.