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

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

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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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


// ------ C.cs

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

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

		

		

		
Ответ 3

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


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


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

		

		
Ответ 4

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


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


Итак, чтобы "вертикальный".


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


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


(Согласитесь с выше, хотя - согласованность имеет жизненно важное значение.
		

		

		
Ответ 5

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


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

		

		
Ответ 6

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


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


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

		

		
Ответ 7

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


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


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

		

		
Ответ 8

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


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


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


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