Namespace, проект, решение. Что это? Какая разница между ними?

Question

Namespace, проект, решение. Что это? Какая разница между ними?

Август Сентябрь Знаток (331), на голосовании 1 месяц назад

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

Считала так:
- Решение - грубо говоря, папка, хранящая несколько проектов (проекты должны быть логически связанны друг с другом - вроде как).
- Проекты - то, что скомпилируется в exe или dll, хранят в себе классы и всякую информацию вроде метаданных.
- Namespace - название для нескольких связанных логикой классов, чтобы их как-то различать

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

2. Должны ли быть логически связанны друг с другом проекты в решении?

3. Проект и namespace - это одно и то же? Или может проект хранит namespace?

4. Если я хочу в другом namespace определить класс, то в обозревателе решений он будет отмечен как другой проект или будет внутри этого проекта?

5. Проекты - разные вещи и собираются в разные exe/dll файлы? Или все будут в один?

И если не трудно:

6. Зачем располагать расширяющие методы в другом namespace?

Поясню:
Чем именно это помогает другим разработчикам? Ведь допустим: создаю расширяющий метод - для этого создаю класс. Его выношу в отдельный файл вне Program.cs. Например, в MyExtension.cs. В коде Program.cs никак не мешает мой расширяющий метод визуально, а также визуально он хранится в проекте том же, что и Program.cs. Зачем выносить его в другой namespace? Даже если вынести, он будет в том же проекте также выглядеть визуально. А логически к нему подключиться нельзя будет - значит я не смогу с ним работать в program.cs. Но чтобы с ним работать я подключу его через using. В таком случае я смогу с ним работать, но и остальные смогут. Какая разница между тем, чтобы выносить в другой Namespace или не выносить? Как по логике (доступен всем), так и внешне (отображается внутри проекта) он работает идентично..

Answer 1

Обычно у каждого решения есть своя папка и у каждого проекта этого решения тоже есть своя отдельная папка.
Технически проекты не обязаны быть связаны, если расположены в одном решении, но помещаются они в одно решение не для красоты, а чтобы ими можно было пользоваться.
Нет, проект это не пространство имён. В одном проекте можно создать иерархическую структуру для своего кода. Каждый набор классов может быть помещён в свой namespace (условно, папку) для организации кода. При этом разные проекты могут использовать одинаковые namespace. Чтобы импортировать какой-то код, какое-то простнатсов имён, пишется using. Да, по-умолчанию твоё пронстранство имён может начинаться с имени твоего проекта, но это совсем не обязательно.
Пространства имён не зависят от проекта.
Если у тебя есть основной проект, который задействует другой проект в качестве библиотеки, тогда другой проект может скопилироваться в виде .dll.
Для того чтобы при использовании using ты не импортировал сразу же и свой расширяющий метод, если он тебе не нужен.

Answer 2

>Что это?
Совершенно разные вещи.

>Какая разница между ними?
А какое между ними вообще сходство о_О?

>Считала так:
В целом правильно.

>Есть ли смысл располагать решение и проект в одном каталоге
Тебе виднее. Иногда экономия длины пути важна для систем контроля версий. Но в целом - дело вкуса. Если путь вида ...\ProjectName\ProjectName\ProjectName.csproj тебя эстетически не смущает, располагай в разных.

>Должны ли быть логически связанны друг с другом проекты в решении?
Скорее физически. Например, удобно хранить в одном решении проект и его библиотеки. Или другие какие-то утилиты, связанные с основным проектом. Или еще всякие ресурсы.

>Проект и namespace - это одно и то же?
Ни в коем случае.

>Или может проект хранит namespace?
Смотри... MSVS предлагает использовать имя проекта и структуру его директорий в качестве пространств имен. Это удобно, это понятно. Но у тебя по этому поводу могут быть свои соображения.

>Если я хочу в другом namespace определить класс, то в обозревателе решений он будет отмечен как другой проект или будет внутри этого проекта?
Я же говорю - никакой связи. У меня часто один и тот же класс может быть включен в несколько проектов одновременно, например:

>Проекты - разные вещи и собираются в разные exe/dll файлы?
Проекты - вещь достаточно условная. Если у тебя там питоновский проект, ни во что он "собираться" не будет вообще. Но да, каждый проект изолирован от другого.

>Зачем располагать расширяющие методы в другом namespace?
Как и любой класс - чтобы избежать конфликта, если вдруг разные расширяющие классы реализуют одинаковые методы. Расширяющий класс (хелпер) не виден, работа происходит с базовым классом, поэтому может случиться ОЙ. Но если ты этого не боишься, можешь так не делать.