Ну вот когда данные должны быть доступны из любого участка кода — тогда и делать статическую переменную. А когда не должны — тогда не делать

Ещё один лагерь: лепят статику как и где попало, лишь бы код был попроще. Когда требуется хранить два состояния вместо одного увольняются и передают работающий код следующему программисту. Который пишет тут ответ объясняющий почему это технологический долг.

"данные были бы доступны почти из любого участка кода" - это дорога в ад. Программы с произвольным доступом к данным чужих модулей очень плохо стартуют. Статический объект A зависит от статического объекта B. Порядок инициализации не задать. Программа то падает на старте с NPE, то стартует нормально. В зависимости от порядка чтения конфигурации по сети. В программе появляется код типа "подождём пять секунд, это хватит чтобы другой модуль подключился к базе". Жуть.

Статика это удобно. Чем больше у вас будет опыта, тем дальше от неё вы будете стараться держаться.

Статика не нужна. Достаточно знать про интерфейс, через который можно получить нужные данные и через DI фреймворк внедрять его реализацию туда, где нужно прочитать эти данные. Ваш код знает только про интерфейс получения данных, а не про конкретный класс, всё по парадигмам.

ru.stackoverflow.com/a/991276/184217

Вы удалили как по мне, довольно важную часть, а именно Допустим, реализуя паттерн MVC в WPF - в WPF не проектируют подобным образом, ибо в WPF нет контроллеров. В WPF используют MVVM, где все делят на слабо связанные друг с другом слои (Model/ViewModel/View), ключевое тут "мало связанные". Ну а теперь представьте, что вы создали например класс настроек, он статичен, вы ссылаетесь на него во всех слоях, нарушая тем самым MVVM, правильно это? Нет, ибо у вас должен быть отдельный, не статичный Model слой отвечающий за настройки, к которому уже обращается нужный VM.

А так, мне кажется вам стоит привести пример того, что вы сейчас делаете, обсудим правильно это или нет, и можно/нужно от этого избавляться. Вам вон правильно говорят, статика хороша в меру, без нее нельзя, но использовать ее повсеместно ради экономии, это дорога в ад. Вы даже уже сами столкнулись с одной из проблем - привязкой статичных данных в WPF, что уже должно насторожить, но нет, вы яро в тот раз настояли на том, что это так и должно быть, хорошо, что всеж решили разобраться в этом.

@StanislavVolodarskiy "Порядок инициализации не задать" - порядок инициализации вполне определён, статический конструктор (который можно переопределить) вызывается перед первым использованием статического объекта.

@rotabor, в сложных программах статики не могут быть инициализированы конструктором полностью. Инициализация двухстадийная: конструктор создаёт пустой статик (статик по-умолчанию), специальная процедура считывает конфигурацию из файла, сервиса, базы данных и заполняет статик реальным содержимым. Проблема статиков в том что компилятор не помогает вам в определении он ещё пуст или уже готов к работе. Вы обязаны заводить поля вроде is_inited и следить за ними.

@StanislavVolodarskiy ну так перенесите код "специальной процедуры" в конструктор, чтобы статик создавался не пустой.

@rotabor, вот мы и получили кучу бизнес логики, которая исполняется в произвольном порядке до начала main. А значит до начала нормальной обработки исключений, до старта логера. Когда такая программа падает на старте, вы даже логов не увидите.

@StanislavVolodarskiy "статический конструктор (который можно переопределить) вызывается перед первым использованием статического объекта" - ничего перед main не вызывается.

@rotabor, вы ошибаетесь. Статики вне функций инициализируются до старта main. Статики внутри функций инициализируются при первом вызове этой функции.

@Ravanson Но про loose coupling то вы слышали?

@Ravanson Статические данные - это сильная связанность, это плохо.

@Ravanson легче использовать статическую коллекцию - Мне легче создать полноценный класс, который будет отвечать за конкретную логику, в котором я могу сделать и нужные проверки добавления, и нужные события, и все остальное, что мне нужно, хранить это все в виде синглтона, и обращаться где угодно как MyClass.Instance.Add(). Ну а если проект большой, то вообще я лично любитель IoC контейнеров, где я просто попрошу через конструктор в нужном месте интерфейс нужной мне логики, все, 2 строки кода. Зачем вот тут статика, не знаю... я реализую - все в вопрос, с примерами кода.

@Ravanson Наверное, вы не писали большие проекты, где в одном солюшене куча отдельных проектов, и толпа народа это всё редактирует. При слабой связности можно скомпилировать свой проект отдельно, без лишнего кода, всё протестировать что хочешь и как хочешь в своём проекте, независимо от того, что там кто-то поменял в других проектах. Интерфейс сохранился - всё компилируется, всё тестируется. А при сильной связности придётся компилировать всегда весь солюшен и если кто-то где-то что-то сломал в каком-то проекте - сиди жди, пока он это починит.

@Ravanson То есть вы никогда совместно код не писали, вам никто Code Review не делал, а тесты то вы хоть пишете?