Пространства имен .NET

Question

Мой фон прежде всего является Java-разработчиком, но в последнее время я занимаюсь некоторой работой в .NET. Поэтому я старался сделать некоторые простые проекты дома, чтобы лучше работать с .NET. Я смог перенести большую часть моего опыта Java в работу с .NET (в частности, на C#), но единственное, что действительно озадачило меня, это пространство имен.

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

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

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

Редактировать: Как заметил Блэр, это почти тот же вопрос, заданный here.

Answer 1

Я не могу утверждать, что это лучшая практика, но я часто вижу файлы, организованные в иерархии каталогов, которая отражает пространство имен. Если это лучше подходит для вашей ментальной модели кода, сделайте это - я не могу придумать никакого вреда. Просто потому, что .NET-модель не обеспечивает отношения между пространствами имен, проектами и структурой каталогов, не означает, что вы не можете иметь такие отношения, если хотите.

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

EDIT: Обратите внимание, что этот вопрос почти дубликат should the folders in a solution match the namespace?

Answer 2

Вы можете добавлять папки решения для каждого пространства имен. Хотя он все равно будет скомпилирован для одного исполняемого файла, он организует ваши исходные файлы и дает (как мне кажется) желаемый эффект?

Я обычно добавить папку для каждого пространства имен в моем проекте, и вкладывать их в соответствии с той же иерархии (MyApp.View.Dialogs, например)

Answer 3

раствор А VS обычно содержит один или несколько проектов. Проекты Thse имеют пространства имен по умолчанию (обычно пространство имен - это просто название проекта). Обычно, если вы добавите папку, в рамках проекта, все классы в нем будут названы следующим образом:

DefaultNamespace.FolderName.ClassName

Конечно, вы можете изменить пространство имен по умолчанию для проекта, и назначьте свои классы любым способом.

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

Также важно помнить, что решение VS не имеет никакого отношения к коду - то есть. они не создаются. VS Solutions - не что иное, как способ группировки проектов; это проекты, которые построены и превращены в библиотеки DLL.

Наконец, VS позволит вам добавлять «виртуальные» папки в любом месте решения. Эти папки не сопоставляются с папкой в ​​файловой системе и просто используются в качестве другого средства, чтобы помочь вам организовать ваши проекты и другие артефакты в решении.

Answer 4

Да, в пространстве имен .NET не зависит от файловой системы или чего-то еще. На мой взгляд, это большое преимущество. Например, вы можете разделить свой код на разные сборки, что позволяет гибко распределять.

При работе в Visual Studio IDE имеет тенденцию вводить новое пространство имен при добавлении новой папки в дерево проекта.

Вот полезная ссылка с MSDN:

Namespace Naming Guidelines

Общим правилом для обозначения пространств имен является использование названия компании, за которой следует названия технологии и необязательно функцию и конструкцию, следующим образом.
CompanyName.TechnologyName [.Feature] [. Дизайн]

Конечно, вы можете использовать пространство имен, как вы найти более подходящий. Однако, если вы собираетесь поделиться своим кодом, я бы рекомендовал придерживаться общепринятых стандартов.

EDIT:

Я настоятельно рекомендую любому разработчику .net, чтобы получить копию Framework design guidelines Эта книга поможет вам понять, насколько и почему .NET предназначен.

Answer 5

Пространства имен являются чисто семантическими. Хотя они обычно отражают структуру папок, по крайней мере, при использовании Visual Studio IDE им не нужно.

У вас может быть такое же пространство имен, на которое ссылаются в нескольких библиотеках, уродливые, но истинные.

Answer 6

Действительно, среда .Net позволяет вам выкидывать свой код в IDE/файловую систему, например спагетти, на стену.

Это не значит, что этот подход является разумным. В целом хорошая идея придерживаться проекта. Имя_файла. Классовый подход, о котором упоминалось ранее. Это также очень хорошая идея - сохранить все классы из одного пространства имен в один класс.

В Java вы можете делать такие же жуткие вещи, как и получить все «гибкость», которые вы хотите, но инструменты, как правило, сильно обескураживают ее. Честно говоря, одна из самых запутанных вещей для меня в том, чтобы быть знакомой с миром .Net, была такой же неряшливой/непоследовательной, что это могло быть связано с относительно плохим руководством. Тем не менее, его легко организовать мелочи с небольшой мыслью.:)

Answer 7

Я всегда рассматривал организацию исходного файла и присваивал идентификаторы классам и объектам как две отдельные проблемы. Я склонен поддерживать связанные классы в группах, но не каждая группа должна быть пространством имен. Пространства имен существуют (более или менее) для решения проблемы конфликтов имен - в языках с пространством имен как C, вы не можете пройти два фута без отключения по идентификаторам, например mycompany_getcurrentdate или MYCGetCurrentDate, поскольку риск конфликта с другой функцией в сторонняя (или системная) библиотека намного меньше. Если вы создали пакет или пространство имен для каждого логического разделения, вы получили бы имена классов Java (например, java.lang.primitivewrapper.numeric.Integer), что в значительной степени переборщило.

Answer 8

Пространства имен являются логической группировкой, а проекты - физической группировкой.

Почему это важно? Подумайте о .NET 2.0, 3.0 и 3.5. .NET 3.0 - это в основном .NET 2.0 с некоторыми дополнительными сборками, а 3.5 добавляет еще несколько сборок. Так, например, .NET 3.5 добавляет элемент управления DataPager, который является веб-элементом управления и должен быть сгруппирован в System.Web.UI.WebControls. Если пространства имен и физические местоположения были идентичны, это не могло быть, потому что это в другой сборке.

Таким образом, наличие пространств имен в качестве независимых логических объектов означает, что вы можете иметь элементы нескольких различных сборок, которые все логически сгруппированы вместе, поскольку они предназначены для использования в сочетании друг с другом.

(Кроме того, нет ничего плохого в том, ваши физические и логические макеты очень похожи.)

Answer 9

разница в том, что .net пространство имен не имеют ничего особенного делать с пакетов Java.

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

Это очень просто все, что объявлено в определенном пространстве имен, доступно, когда вы включаете 'использование' в это пространство имен.

очень простой.

выбор имени и независимо от того, сколько или сколько. Сепараторы, которые вы используете, полностью зависят от вас.

VS по умолчанию добавляет .foldernames к вашим пространствам имен, чтобы попробовать и быть полезным.

эта статья объясняет пространств имен вполне хорошо: http://www.blackwasp.co.uk/Namespaces.aspx

Он также имеет пример именования к концу, хотя ваше имя конвенции Ваш звонок! ;)

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