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

https://stackoverflow.com/questions/55692

09-06-2019
|

Вопрос

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

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

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

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

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

Решение

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

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

РЕДАКТИРОВАТЬ:Обратите внимание, что этот вопрос почти дублирует вопрос должны ли папки в решении соответствовать пространству имен?

Другие советы

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

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

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

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

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

РЕДАКТИРОВАТЬ:

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

Решение VS обычно содержит один или несколько проектов.Эти проекты имеют пространства имен по умолчанию (обычно пространство имен — это просто имя проекта).Обычно, если вы добавляете папку в проект, все классы в ней будут называться следующим образом:

Пространство имен по умолчанию. Имя папки. Имя класса

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

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

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

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

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

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

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

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

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

Однако это не означает, что такой подход разумен.Обычно рекомендуется придерживаться подхода project.имя_папки.Класс, упомянутого ранее.Также очень хорошая идея — хранить все классы из одного пространства имен в одном классе.

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

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

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

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

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

Выбор имени и то, сколько/сколько '.' Seperators, которые вы используете, полностью зависит от вас.

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

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

В конце также есть пример соглашения об именах, хотя ваше соглашение об именах — это ваш вызов!;)

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

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

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

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

Вы можете использовать одно и то же пространство имен в нескольких библиотеках, некрасиво, но это правда.

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow