Introduction

ObservableCollection<T> is designed for change notifications, not for built-in sorting. That is why it supports add, remove, and move operations but does not expose a Sort method. In practice, you choose between sorting the UI view or reordering the underlying collection itself.

Decide Whether the View or the Source Should Be Sorted

The first design choice is whether sorting is only for display or whether the collection’s actual order matters to the application logic.

If the goal is display-only sorting, sorting the view is usually better because the underlying collection remains unchanged. If business logic, persistence, or export order depends on the sorted result, then the source collection itself has to be reordered.

Sort the View with ICollectionView

In WPF, view-level sorting is often the cleanest option.

1using System.ComponentModel;
2using System.Windows.Data;
3
4ICollectionView view = CollectionViewSource.GetDefaultView(MyItems);
5view.SortDescriptions.Clear();
6view.SortDescriptions.Add(
7    new SortDescription(nameof(Item.Name), ListSortDirection.Ascending)
8);
9view.Refresh();

This keeps the source collection untouched while giving the UI a sorted presentation. It is especially useful when different screens need different sort orders over the same data.

Reorder the Source with Move

If the ObservableCollection<T> itself must become sorted, use Move operations so bindings receive incremental notifications.

1using System;
2using System.Collections.ObjectModel;
3using System.Linq;
4
5public static class ObservableCollectionExtensions
6{
7    public static void SortInPlace<T, TKey>(
8        this ObservableCollection<T> source,
9        Func<T, TKey> keySelector,
10        bool descending = false)
11    {
12        var sorted = descending
13            ? source.OrderByDescending(keySelector).ToList()
14            : source.OrderBy(keySelector).ToList();
15
16        for (int targetIndex = 0; targetIndex < sorted.Count; targetIndex++)
17        {
18            var item = sorted[targetIndex];
19            int currentIndex = source.IndexOf(item);
20            if (currentIndex != targetIndex)
21            {
22                source.Move(currentIndex, targetIndex);
23            }
24        }
25    }
26}

Move is better than clearing and re-adding because it preserves more UI state and avoids treating every item as newly inserted.

Clear and Rebuild Is Simpler but Rougher

A simpler option is to sort into a list, clear the collection, and add the items back.

1var ordered = MyItems.OrderBy(x => x.Name).ToList();
2MyItems.Clear();
3
4foreach (var item in ordered)
5{
6    MyItems.Add(item);
7}

This works, but it can reset selection, scroll position, and container state in the UI. It is acceptable for small lists or non-interactive views, but it is not the best default for a bound desktop interface.

Respect UI Thread Rules

Most UI frameworks require collection mutations on the UI thread. That includes sorting. If expensive data preparation happens in the background, marshal only the final collection updates back to the UI thread.

1await Task.Run(() =>
2{
3    sortedData = repository.Load().OrderBy(x => x.Name).ToList();
4});
5
6Application.Current.Dispatcher.Invoke(() =>
7{
8    MyItems.Clear();
9    foreach (var item in sortedData)
10    {
11        MyItems.Add(item);
12    }
13});

Threading mistakes around ObservableCollection<T> often look like sorting bugs because they only appear when bindings refresh.

Add Tie-Breakers for Stable Results

If the primary sort key has duplicates, add secondary ordering so the visible result remains predictable.

1var ordered = MyItems
2    .OrderBy(x => x.Priority)
3    .ThenBy(x => x.Name)
4    .ToList();

This improves consistency, especially in lists that refresh often.

Common Pitfalls

The biggest mistake is expecting OrderBy to mutate ObservableCollection<T> directly. LINQ returns a new sequence; it does not reorder the collection for you.

Another issue is sorting the bound collection off the UI thread, which causes cross-thread update errors.

Clearing and rebuilding large collections can also create flicker and destroy useful UI state when a view-level sort would have been enough.

Summary

• 'ObservableCollection<T> does not have a built-in Sort method.'
• Use ICollectionView when only the UI presentation needs sorting.
• Use Move-based reordering when the source collection itself must change order.
• Be careful with UI-thread rules when mutating bound collections.
• Add deterministic secondary sort keys so repeated refreshes stay predictable.