Я знаю, что это несколько субъективно, но мне интересно, существует ли общепринятый стандарт для именования сборок, содержащих некоторые "основные" функции.
Скажем, вы получили более крупные проекты, с ассемблиями вроде
и у вас есть куча "основных" классов, таких как глобальный обработчик ошибок, глобальная функция ведения журнала и т.д.
Как бы такая сборка вообще называлась? Вот некоторые вещи, которые я имел в виду:
Теперь, когда "просто выберите один и продолжай" не вызовет Армагеддон, мне все равно хотелось бы знать, есть ли "принятый" способ назвать эти сборки.
С .Net это относительно легко изменить, поэтому я бы пошел с удобством.
Меньше, больше, сборки собираются быстрее, чем многие маленькие, поэтому я бы начал с вашего "основного" материала в качестве пространства имен внутри Company.Product.dll и позже разделил его, если вам нужно.
Все эти "root", "core", "common" и т.д. действительно являются плохими соглашениями об именах.
Общие вещи должны лежать в корневом пространстве имен, например, в .NET, string, int и другие вещи, которые являются "ядром" или "общим", находятся в корневом пространстве System -namespace.
Не используйте пространства имен для более простого сглаживания ваших папок в Visual Studio, но структурируйте его после того, что он содержит, и того, что он использовал для.
System.Security содержит общие вещи безопасности, о которых, например, System.Xml не нужно знать, если вы явно не хотите эту функциональность.
System.Security.Cryptography - это пространство под-имен. Криптография - это безопасность, но защита явно не криптография.
Таким образом, System.Security.Cryptography имеет полное понимание его родительского пространства имен и может подразумевать использование всех классов внутри своего родителя.
Я бы сказал, что System.Core.dll был slip-up на стороне Microsoft. Они, должно быть, исчерпали идеи или имена DLL.
Обновление. MSDN имеет несколько обновленную статью которая пытается объяснить Microsoft мышление по этому вопросу.
Мне обычно нравятся имена, которые описывают, что находится внутри каждой сборки.
Понимаете, если вы назовете что-то вроде .Core, то в большой команде он может расти очень быстро, так как люди рассмотрят возможность размещения в этой сборке очень распространенной вещи.
Итак, я думаю, что на самом деле не должно быть одной основной сборки.
Я использовал .Core,.Framework и .Common.
Мы используем эту модель:
и др.
Я всегда делаю .Core.dll.
Тот, который я использую наиболее часто и, кажется, люблю, потому что я не вижу, чтобы другие люди использовали его Root
Я обычно буду делать
CompanyName.Root
или
SomethingMeaningfulToMe.Root
Это одна из тех, которые зависят от вопросов. Если ваш код и вы работаете в небольшой команде, я бы использовал любое соглашение об именах, которое имеет смысл для вас. Тем не менее, я видел, что в больших пространствах имен кодов базы данных позволяют разработчикам нисходящего потока открывать функциональные возможности без необходимости документирования или обучения. мы используем модель. стандартизация пространств имен упрощала разработчикам переводить команду в команду.
BussinessName.Division.Layer
i также используется .Core, особенно для .dll
Все это вопрос вкуса imo, если корневое пространство имен - это название компании, я чувствую. Core/framework/common более описателен, чем просто название компании.
Однако, если вы работаете над чем-то вроде проекта с открытым исходным кодом, где имя пространства dll/namespace также является именем проекта,.Core/../может быть немного избыточным.
В .NET Framework и других библиотеках Microsoft есть много примеров, в которых используются оба соглашения. например, есть System.dll и System.Core.dll:)
Core - это очень значимое и понятное для понимания соглашение об именах, и оно не конфликтует с каким-либо пространством имен .net, поэтому это очень хорошая практика.
Я настоятельно рекомендую инкапсулировать в каждой сборке службу, которую он предположил, предоставить прикладной программе, которая ее использует, и не смешивать разные домены функций в одной сборке.
Мы используем
CSG.Core
CSG.Data
CSG.Services
...
В ядре мы включаем классы, которые, вероятно, будут использоваться во всех наших продуктах: ведение журнала, сборные расширения, обобщения, расширения конфигурации, безопасность, проверка и т.д.
Несмотря на то, что сборка множества сборок происходит медленнее, чем меньше и больше сборки, она оптимизирует развертывание, поскольку вы развертываете только те классы, которые используются вашей системой, и не содержат много классов, которые не используются только потому, что вы хотите сохранить время компиляции.
Когда вы называете свои пространства имен, я настоятельно рекомендую избежать повторения одного и того же слова на другом уровне пространства имен. Например, избегайте следующего:
YourCompany.Core
YourCompany.YourProduct.Core
Поместите ядро в свою компанию или в Myproduct, но не в оба. Это может быть очень запутанным, если, например, ваше использование выглядит так: использование YourCompany; с помощью YourCompany.YourProduct;
Когда вы наберете Core.SomeClass, это будет очень запутанным, откуда пришел этот класс, и если у вас есть 2 класса с тем же именем, это вызовет конфликт.