Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

Wiele osób potrafi pomylić, która kolekcja faktycznie nadaje się do powiązania z elementem UI, szczególnie gdy pracują z .NET i mają do wyboru tyle różnych klas. Collection czy KeyedCollection mogą kusić, bo na pierwszy rzut oka wydają się elastyczne – Collection to po prostu bazowa kolekcja generyczna, można ją dziedziczyć i rozszerzać, ale nie powiadamia automatycznie interfejsu o zmianach. KeyedCollection to niby sprytna hybryda listy i słownika, czasem się przydaje, gdy potrzebujesz szybkiego wyszukiwania po kluczu, ale znowu – nie ma mechanizmu powiadomień, więc UI się w ogóle o niczym nie dowie. Niektórzy błędnie myślą, że jakakolwiek kolekcja generyczna wystarczy do zbudowania dynamicznego widoku, ale to niestety prowadzi do konieczności manualnego odświeżania widoków albo tworzenia niepotrzebnych wrapperów. ReadOnlyCollection wydaje się atrakcyjna, bo zapewnia bezpieczeństwo, nie pozwala na modyfikacje przez użytkownika, ale tak naprawdę to tylko opakowanie, które nie wnosi żadnych zdarzeń informujących o zmianach. Moim zdaniem, jeśli zależy Ci na nowoczesnym, elastycznym i dynamicznym interfejsie opartym o wzorce MVVM czy MVU, to tylko ObservableCollection daje sensowne narzędzia do pracy. Pozostałe typy kolekcji są świetne, ale bardziej do scenariuszy nieinteraktywnych albo tam, gdzie synchronizacja z widokiem nie jest wymagana. Typowym błędem jest myślenie, że wystarczy po prostu zamienić List na cokolwiek innego, a UI się jakoś „odświeży” samo – to niestety tak nie działa. Prawidłowe powiązanie danych w .NET wymaga wsparcia dla notyfikacji zmian, a to zapewnia wyłącznie ObservableCollection i implementacje interfejsów powiadamiających o zmianie stanu kolekcji.