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

Question

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

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

• Поместите все типы сборки в один исходный файл. Один из друзей, который сделал это, сказал, что «файлы - это инструмент организации архивного кода, сегодня я использую класс и 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

Я делаю это совершенно аналогично. Одна точка, где я отличаюсь:

• один тип каждого файла

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

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

(Необходимо согласиться с выше, хотя - последовательность жизненно важна.

Answer 8

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

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

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