Честно говоря, при плоском словаре
[...] список вырастет огромным, и читаемость будет затруднена, если мне придется посмотреть, какие у нас есть коды ошибок для конкретного c код состояния.
не очень хорошее оправдание, чтобы сделать код чрезмерно сложным и менее производительным. Хотя читаемость Dictionary<int, List<int>>
могла бы быть немного лучше, читаемость самого кода (и это должен быть код, который имеет значение) пострадает. ИМХО, это скорее симптом субоптимальной структуры кода.
При использовании плоского словаря поиск становится таким простым, как
int GetHttpStatus(int errorCode)
{
return errorCodeMappings[errorCode];
}
И поскольку ключ не может существовать более одного раза в словаре, не существует способа умножения кодов ошибок.
(Плюс, это супербыстрое по сравнению с решением, использующим Dictionary<int, List<int>>
с обратным поиском, потому что вы можете использовать хеширование. Хотя это, скорее всего, не будет узким местом, приятно иметь бесплатно.)
Если вы обернули это в некоторый класс StatusCodeMapper
, вы можете определить свой конструктор как
public ErrorCodeMapper(Dictionary<int, List<int>> reverseMappings)
{
// Convert mappings to a more efficient format
this.mappings = reverseMappings.SelectMany(entry => entry.Value.Select(errorCode => new { errorCode, status=entry.Key}))
.ToDictionary(mapping => mapping.errorCode, mapping => mapping.status)
}
и сохранить свой Dictionary<int, List<int>>
на верхнем уровне, но используйте более краткий и быстрый поиск и автоматическую c проверку на наличие дубликатов кодов ошибок, которые вы получаете с помощью Dictionary
, если использовать их по назначению. Если вы создадите только один экземпляр ErrorCodeMapper
, «дорогой» код (ну, не слишком дорогой, но более чем на 10 * * поиск) будет запущен только один раз.