Отдельные проекты или несколько файлов класса … лучшая практика пространства имен в C#
Я создаю библиотеку для использования с приложением, которое я создаю. Я создаю структуру пространства имен, подобную ниже.
MyNamespace.Validation
MyNamespace.Reports
MyNamespace.Transactions
MyNamespace.DataImport
etc...
Это была бы лучшая практика для создания решения с несколькими проектами для каждого sub пространства имен или одним проектом с несколькими файлами класса для каждого sub пространства имен?Спасибо.
5 ответов
У обоих подходов есть свои плюсы и минусы, и вам нужно выбрать один из них, исходя из ваших собственных обстоятельств.
Поддержка нескольких проектов:
- Отдельные сборки позволяют компилятору предоставлять более строгие указания, потенциально предотвращая постепенное связывание. Это позволяет лучше поддерживать зависимости.
- Отдельные сборки могут быть загружены по мере необходимости в другие проекты, что потенциально упрощает повторное использование.
- Отдельные сборки могут предотвратить загрузку ненужного кода в процесс, поскольку они загружаются по запросу.
Недостатки нескольких проектов:
- Более сложное развертывание, поскольку требуется развертывание большего количества файлов (незначительное)
- Более медленная сборка / компиляция и даже потенциально время загрузки из-за загрузки нескольких сборок (незначительное)
Лично я думаю в большинстве случаев плюсы намного перевешивают минусы.Обычно я разделяю свои пространства имен на отдельные сборки, если они не связаны. В вашем случае вы работаете над четырьмя очень разными концепциями, поэтому я интуитивно чувствую, что разделение имеет наибольший смысл.
Я бы выбрал одно решение с несколькими проектами.
Преимущества:
- Каждый проект может быть отдельной dll
- Все проекты в одном решении для удобной навигации между файлами
BufferedReader, вероятно, обеспечит вам лучшую производительность (поскольку Scanner основан на InputStreamReader, ищите источники)., для чтения из файлов используется nio. При тестировании производительности nio по сравнению с производительностью BufferedReader для больших файлов nio показывает немного лучшую производительность.- Для чтения из файла попробуйте Apache Commons IO.
Я обычно следовал образцу, при этом одна сборка является одним пространством имен, а имя DLL находится в пространстве имен. Проще найти библиотеки DLL для справки
-121--4585714-Я бы сказал, что это зависит.
- Во-первых, рекомендуется поместить каждый класс в свой собственный файл.
- Если вы идете с одним проектом, я бы создал папки для каждого пространства имен внутри этого проекта и поместил файлы кода в соответствующую папку.
- При выполнении вышеописанного Visual Studio автоматически создаст новые файлы классов в пределах правильного пространства имен
Я думаю, что реальный вопрос здесь заключается в следующем:
Если это когда-либо будет использоваться только один раз, размещение всего в одном проекте будет иметь смысл. Однако если этот код будет повторно использоваться, следует подумать, можно ли повторно использовать только часть (или одно вложенное пространство имен) этой библиотеки. Если ответ да, я бы разбил пространства имен на отдельные проекты, так что в будущем вы могли бы включить только нужные вам проекты.
Сканер используется для синтаксического анализа маркеров из содержимого потока, в то время как BufferedReader просто считывает поток и не выполняет никакого специального синтаксического анализа.
Фактически можно передать BufferedReader сканеру в качестве источника символов для синтаксического анализа.
BufferedReader, вероятно, обеспечит вам лучшую производительность (поскольку Scanner основан на InputStreamReader, ищите источники)., для чтения из файлов используется nio. При тестировании производительности nio по сравнению с производительностью BufferedReader для больших файлов nio показывает немного лучшую производительность.- Для чтения из файла воспользуйтесь функцией ввода-вывода Apache Commons.
Я обычно следовал образцу, при этом одна сборка является одним пространством имен, а имя DLL находится в пространстве имен. Проще найти библиотеки DLL для ссылки
Решение о том, как именно разбить ваше решение, является субъективным и действительно зависит от специфики вашего кода.
Однако одно можно сказать наверняка: поддержка нескольких сборок имеет недостатки! Эта статья особенно хороша для описания этих недостатков, наблюдения за тем, как они увеличивают затраты во время разработки, компиляции, развертывания и выполнения.
Я использую как можно меньше сборок, стремясь создать единую сборку, при этом изолируя нестабильные области домена. Когда несколько сборок явно подходят или требуются (а это часто бывает, особенно для обеспечения разделения), я делаю все возможное, чтобы сгруппировать интерфейсы, которые будут изменяться одновременно, в одни и те же сборки.