Как вы организовываете код C # в файлы?

Question

В C # вопросы о том, какие типы создавать, какие члены они должны иметь и какие пространства имен должны их содержать, являются вопросами дизайна ОО. Это не те вопросы, которые меня интересуют.

Вместо этого я хочу спросить, как вы храните их в дисковых артефактах. Вот несколько примеров правил:

• Поместите все типы сборок в один исходный файл. Один из моих друзей сказал, что «файлы - это инструмент организации архаичного кода; сегодня я использую classview и Collapse to Definitions для просмотра своего кода».

• Поместите весь свой код в одну сборку. Упрощает развертывание и управление версиями.

• Структура каталогов отражает структуру пространства имен.

• Каждое пространство имен получает собственную сборку.

• Каждый тип идет в своей сборке. (Перечислен как крайний пример.)

• Каждый тип получает свой собственный исходный файл.

• Каждый участник получает свой собственный файл; каждый тип получает свой собственный каталог. (Перечислено как крайний пример.)

Answer 1

Что бы вы ни делали, просто ПОЖАЛУЙСТА, делайте это последовательно. Я не верю, что есть один единственный ответ (хотя есть несколько неправильных). Но просто убедитесь, что вы остаетесь верны своей форме, так как это станет ключом для ваших преемников, чтобы легко находить вещи.

Answer 2

В настоящее время я делаю:

• Одна сборка для производственного кода + модульные тесты
• структура каталогов имитирует пространства имен
• один тип на файл
  • вложенные типы получают свои собственные файлы, используя partial типы. То есть:

// ------ C.cs

public partial class C : IFoo
{
    // ...
}

// ------ C.Nested.cs
partial class C
{
    public class Nested
    {
        // ...
    }
}

Answer 3

Я создаю одну сборку на архитектурный слой. (WinUI.exe, BusinessWorkflow.dll, BusinessComponent.dll и т. Д.

Затем по одному физическому файлу на класс.

Так что это "вертикаль".

Пространства имен, концептуально, идут горизонтально, группируя функциональные возможности уровня домена вместе. Вся информация о клиенте отправляется в пространство имен «Клиент», например, «Заказы» входят в «Accounting.AccountsPayable», например.

Поскольку каждая сборка ссылается только на одну, расположенную под ней, - архитектурно, ваш смысл хорошо ограничен соответствующими ссылками в вашей доменной модели.

(Приходится соглашаться с вышесказанным - последовательность важна.

Answer 4

Я делаю это очень похоже. Одна точка, в которой я отличаюсь:

• один тип на файл

Я объявляю типы делегатов там, где они мне нужны, то есть не в их собственном файле, а в классе, который их использует.

Answer 5

Независимо от того, насколько мал тип, поместите каждый тип в отдельный файл - Исключение: вложенные классы и делегаты

Кстати, использование частичного класса для разделения с единственной целью размещения вложенного типа в своем собственном файле выглядит излишним. Частичные классы должны использоваться разумно и, как правило, использоваться для инструментов генерации файлов. Вы должны подумать, как «назвать» ваши частичные классы для вложенных классов. Создание интуитивно понятного имени для физического вложенного файла может быть утомительным, и это определенно непростая задача.

Для проектов назовите свои проекты так, чтобы они отражали пространства имен - Исключение: когда вложенное пространство имен становится большим, я бы перенес вложенную папку в другой проект.

Answer 6

Для крошечных проектов с менее чем десятком классов, только один класс на файл.

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

Answer 7

Я предпочитаю такую ​​организацию на любом языке.

Связанные небольшие классы в своих файлах.

Большие классы в своем собственном файле.

Каталоги для отдельных подпроектов.

Answer 8

Я предпочитаю обычный один файл на публичный класс с папками внутри проекта (которые сопоставляются с подкаталогами), используемыми для группирования концептуально связанных классов по мере необходимости, чтобы поддерживать представление обозревателя решений управляемым. Если ваши имена классов выбраны правильно, папки не должны быть строго необходимыми, но они полезны, если в проекте много классов.

Использование отдельных файлов для вложенных типов выглядит излишним, по крайней мере, если вложенные классы являются относительно простыми «вспомогательными» классами, особенно если они являются закрытыми.

Основное практическое возражение против схемы "все в одном огромном файле" вашего друга заключается в том, что Visual Studio имеет тенденцию работать очень, очень медленно, когда пытается работать с файлами очень длинного кода.