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

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

8 голосов
/ 11 сентября 2008

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

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

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

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

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

Ответы [ 3 ]

11 голосов
/ 11 сентября 2008

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

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

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

4 голосов
/ 11 сентября 2008

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

DefaultNamespace.FolderName.ClassName

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

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

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

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

2 голосов
/ 11 сентября 2008

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...