Именование "основной" Ассамблеи

Ответ 1

С .Net это относительно легко изменить, поэтому я бы пошел с удобством.

Меньше, больше, сборки собираются быстрее, чем многие маленькие, поэтому я бы начал с вашего "основного" материала в качестве пространства имен внутри Company.Product.dll и позже разделил его, если вам нужно.

Ответ 2

Все эти "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 мышление по этому вопросу.

Ответ 3

Мне обычно нравятся имена, которые описывают, что находится внутри каждой сборки.

Понимаете, если вы назовете что-то вроде .Core, то в большой команде он может расти очень быстро, так как люди рассмотрят возможность размещения в этой сборке очень распространенной вещи.

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

Ответ 4

Я использовал .Core,.Framework и .Common.

Ответ 5

Мы используем эту модель:

• Company.Core.dll
• Company.WinControls.dll
• Company.WebControls.dll
• Company.Product.Core.dll
• Company.Product.WinControls.dll
• Company.Product.WebControls.dll

и др.

Ответ 6

Я всегда делаю .Core.dll.

Ответ 7

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

Я обычно буду делать

CompanyName.Root

или

SomethingMeaningfulToMe.Root

Ответ 8

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

BussinessName.Division.Layer

Ответ 9

i также используется .Core, особенно для .dll

Все это вопрос вкуса imo, если корневое пространство имен - это название компании, я чувствую. Core/framework/common более описателен, чем просто название компании.

Однако, если вы работаете над чем-то вроде проекта с открытым исходным кодом, где имя пространства dll/namespace также является именем проекта,.Core/../может быть немного избыточным.

В .NET Framework и других библиотеках Microsoft есть много примеров, в которых используются оба соглашения. например, есть System.dll и System.Core.dll:)

Ответ 10

Core - это очень значимое и понятное для понимания соглашение об именах, и оно не конфликтует с каким-либо пространством имен .net, поэтому это очень хорошая практика.

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

Мы используем

CSG.Core
CSG.Data
CSG.Services
...

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

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

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

YourCompany.Core
YourCompany.YourProduct.Core

Поместите ядро ​​в свою компанию или в Myproduct, но не в оба. Это может быть очень запутанным, если, например, ваше использование выглядит так:   использование YourCompany;   с помощью YourCompany.YourProduct;

Когда вы наберете Core.SomeClass, это будет очень запутанным, откуда пришел этот класс, и если у вас есть 2 класса с тем же именем, это вызовет конфликт.