Namespace, проект, решение. Что это? Какая разница между ними?
Изучаю расширяющие методы, сказали, что дурная практика их располагать прямо в том же 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 или не выносить? Как по логике (доступен всем), так и внешне (отображается внутри проекта) он работает идентично..
>Что это?
Совершенно разные вещи.
>Какая разница между ними?
А какое между ними вообще сходство о_О?
>Считала так:
В целом правильно.
>Есть ли смысл располагать решение и проект в одном каталоге
Тебе виднее. Иногда экономия длины пути важна для систем контроля версий. Но в целом - дело вкуса. Если путь вида ...\ProjectName\ProjectName\ProjectName.csproj тебя эстетически не смущает, располагай в разных.
>Должны ли быть логически связанны друг с другом проекты в решении?
Скорее физически. Например, удобно хранить в одном решении проект и его библиотеки. Или другие какие-то утилиты, связанные с основным проектом. Или еще всякие ресурсы.
>Проект и namespace - это одно и то же?
Ни в коем случае.
>Или может проект хранит namespace?
Смотри... MSVS предлагает использовать имя проекта и структуру его директорий в качестве пространств имен. Это удобно, это понятно. Но у тебя по этому поводу могут быть свои соображения.
>Если я хочу в другом namespace определить класс, то в обозревателе решений он будет отмечен как другой проект или будет внутри этого проекта?
Я же говорю - никакой связи. У меня часто один и тот же класс может быть включен в несколько проектов одновременно, например:
>Проекты - разные вещи и собираются в разные exe/dll файлы?
Проекты - вещь достаточно условная. Если у тебя там питоновский проект, ни во что он "собираться" не будет вообще. Но да, каждый проект изолирован от другого.
>Зачем располагать расширяющие методы в другом namespace?
Как и любой класс - чтобы избежать конфликта, если вдруг разные расширяющие классы реализуют одинаковые методы. Расширяющий класс (хелпер) не виден, работа происходит с базовым классом, поэтому может случиться ОЙ. Но если ты этого не боишься, можешь так не делать.
Обычно у каждого решения есть своя папка и у каждого проекта этого решения тоже есть своя отдельная папка.
Технически проекты не обязаны быть связаны, если расположены в одном решении, но помещаются они в одно решение не для красоты, а чтобы ими можно было пользоваться.
Нет, проект это не пространство имён. В одном проекте можно создать иерархическую структуру для своего кода. Каждый набор классов может быть помещён в свой namespace (условно, папку) для организации кода. При этом разные проекты могут использовать одинаковые namespace. Чтобы импортировать какой-то код, какое-то простнатсов имён, пишется using. Да, по-умолчанию твоё пронстранство имён может начинаться с имени твоего проекта, но это совсем не обязательно.
Пространства имён не зависят от проекта.
Если у тебя есть основной проект, который задействует другой проект в качестве библиотеки, тогда другой проект может скопилироваться в виде .dll.
Для того чтобы при использовании using ты не импортировал сразу же и свой расширяющий метод, если он тебе не нужен.