Dangreon,

файлы чего? код? Данные?

Dangreon,

если у вас файл с кодом на 5-10 к - у вас большие проблемы с архитектурой, или она отсутствует как класс.
Такие файлы могут быть только в инфраструктурных классах, потому что уровень решаемых ими задач обычно намного сложнее бизнес-задач.
В качестве бонуса к таким файлам прилагаются более частые и серьёзные конфликты при совместной разработке (если вы конечно используете систему контроля версий).
Предел класса, который еще более-менее может переварить программист - это 300 строк.

Dangreon,

Бизнес логика в формах - это недопустимо. Выности ее в бизнес-объекты. Сами формы надо компонентизировать, и собирать большую форму из маленьких юзер-контролов.
Но в общем факт отсутсвия архитектуры теперь более ясно виден.

Dangreon,

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

skyANA Принципы, паттерны и методики гибкой разработки на языке C#
Поддержку. Боб Мартин тоже заслуживает внимания.

DangreonSolYUtor, спасибо! столько всего, будет чем заняться)
Вот только работы здесь не на один месяц) С чего начать то? С книжки по рефакторингу?
Рапробование архитектуры не быстрый процесс. Из всего этого я бы начал читать так:
1. Принципы проектирования от Роберта Мартина
2. Чистый код тоже Роберта Мартина.
3. Фаулер, Шаблоны приложений. Это тяжёлая книжка, и как роман ее не почитаешь.

Между делом можно прочитать рефакторинг (там первые 100 страниц где-то просвещающие), а дальше использовать как справочник.

beg-in-erможно викинуть тело метода в статику
Это допустимо только в случае pure function. Т.е. методов, которые
- не зависят от состояния.
- не изменяют состояние системы.
- результат зависит только от переданных аргументов.

beg-in-erу поведайте мне, за что вы не любите мощнейший подход?
может вы позабыли или не в курсе его ИСТИННОЙ мощи?
я без шуток и троления.
а то все говорят, что статики это говно , но что то как то вяло аргументируя.

Правду говорят. А мощь только в объёме головной боли.
Почему любят статики? Потому что их "удобно" использовать как способ глобального доступа к ресурсам. А это и есть основная проблема. Фактически, речь идёт о глобальных данных, доступных всему приложению в любой точке. Это же и есть основная проблема singleton'а. Про вред глобальных данных можно прочитать в любой приличной книжке по программированию, да и гугл даст ссылок по полной.
Такой подход создаёт жесткую связанность, и на корню убивает возможность пострения модульного приложения.
Не большой пример. У нас есть небольшой класс:


Классно, да? В любом месте можно взять и заюзать класс, и он будет работать. Отлично, все рады. До тех пор, пока не появляется вторая база данных, с другой строкой соединения. Можно придумать всяких свичей и ифов, но правильный вариант выглядит так:



В такой класс можно подсунуть любую строку соединения, в любом приложении, и он всегда будет работать.

beg-in-erвсё равно все методы статичны по своей природе.
Не подскажите, как сделать статический метод виртуальным, и переопределить его в наследнике?