Можно ли использовать int для ключа в KeyedCollection

Возможно, лучше всего добавить метод GetById(int) к типу коллекции. Вместо этого можно использовать Collection<T>, если вам не нужен другой ключ для доступа к содержащимся объектам:

public class FooCollection : Collection<Foo>
 { Dictionary<int,Foo> dict = new Dictionary<int,Foo>();

   public Foo GetById(int id) { return dict[id]; }

   public bool Contains(int id) { return  dict.Containskey(id);}

   protected override void InsertItem(Foo f)
    { dict[f.Id] = f;
      base.InsertItem(f);
    }

   protected override void ClearItems()
    { dict.Clear();
      base.ClearItems();
    }

   protected override void RemoveItem(int index)
    { dict.Remove(base.Items[index].Id);
      base.RemoveItem(index);
    }

   protected override void SetItem(int index, Foo item)
    { dict.Remove(base.Items[index].Id);
      dict[item.Id] = item;
      base.SetItem(index, item);
    }
 }









 }

Ключ в KeyedCollection должен быть уникальным и быстро выводиться из собираемого объекта. Например, для класса человека это может быть свойство SSN или, возможно, даже объединение свойств FirstName и LastName (если известно, что результат уникален). Если идентификатор действительно является полем собираемого объекта, то он является допустимым кандидатом на ключ. Но, возможно, попробуйте преобразовать его как строку, чтобы избежать столкновения.

Простым решением могло бы быть преобразование int в другой тип, чтобы создать отдельный тип для разрешения перегрузки. Если вы используете struct, эта оболочка не имеет дополнительных накладных расходов:

struct Id {
    public int Value;

    public Id(int value) { Value = value; }

    override int GetHashCode() { return Value.GetHashCode(); }

    // … Equals method.
}

По сути, вам нужно решить, будут ли пользователи класса сбиты с толку тем фактом, что они, например, не могут:

for(int i=0; i=< myCollection.Count; i++)
{
    ... myCollection[i] ...
}

хотя они, конечно, могут использовать foreach или использовать приведение:

for(int i=0; i=< myCollection.Count; i++)
{
    ... ((Collection<MyType>)myCollection)[i] ...
}

Это непростое решение, так как оно может легко привести к вирусным ошибкам. Я решил разрешить это в одном из своих приложений, где доступ пользователей класса был почти исключительно по ключу.

Я не уверен, что сделал бы это для общей библиотеки классов: в целом я бы избегал раскрытия KeyedCollection в общедоступном API: вместо этого я бы предоставил IList <T> в общедоступном API и потребителей API, которые при необходимости ключевого доступа можно определить собственную внутреннюю коллекцию KeyedCollection с помощью конструктора, который принимает IEnumerable <TItem> и заполняет им коллекцию. Это означает, что вы можете легко создать новую коллекцию KeyedCollection из списка, полученного из API.

Что касается сериализации, существует также проблема производительности что я сообщил в Microsoft Connect: KeyedCollection поддерживает внутренний словарь, а также список и сериализует оба - достаточно сериализовать список, поскольку словарь можно легко воссоздать при десериализации.

По этой причине, а также из-за ошибки XmlSerialization, я бы рекомендовал вам избегать сериализации KeyedCollection - вместо этого сериализуйте только список KeyedCollection.Items.

Мне не нравится предложение обернуть ваш ключ int в другой тип. Мне кажется неправильным добавлять сложность просто для того, чтобы тип мог использоваться как элемент в KeyedCollection. Я бы использовал строковый ключ (ToString) вместо этого - это скорее похоже на класс VB6 Collection.

FWIW, я спросил тот же вопрос некоторое время назад на форумах MSDN. Есть ответ от члена команды FxCop, но нет окончательных рекомендаций.