соглашения о присвоении имен

Question

Предполагая, что у вас есть пространство имен, которое полезно для более чем одного проекта в вашей компании, в формате «MyCompany.Core», у вас будет сборка, названная точно так же, или просто «Core». Почему или почему нет?

Answer 1

Используйте стандартные соглашения об именах .NET, здесь указаны имена сборок . Я спасу тебя (короткое) чтение:

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

Рассмотрите возможность именования DLL в соответствии с следующий шаблон:
<Company>.<Component>.dll
Где <Component> содержит один или несколько Пункты, разделенные точками.

Например, Contoso.WebControls.dll.

Answer 2

Я считаю, что лучше (мнение здесь!) Назвать сборку после корневого пространства имен, которое она содержит, в вашем случае MyCompany.Core.dll . Вы никогда не знаете, попадет ли этот файл за пределы компании, и в целом его отслеживать проще.

Представьте, что если Microsoft назвала System.Core просто Core.dll (System.Core) , то у вас было Core.dll (MyCompany.Core) .... вы представляете, как это быстро становится волосатым.

Answer 3

Я предпочитаю MyCompany.ApplicationName.Core.DLL, это исключает вероятность конфликта, если в MyCompany есть два или более приложений.

Answer 4

Я бы назвал сборку такой же, как корневое пространство имен. Это позволяет легко определить, какой код в какой сборке, и предотвращает конфликты с другими проектами (от других компаний), которые также могут использовать неоднозначное имя «Core.dll».

Answer 5

при разработке в корпоративной среде может пригодиться это соглашение:

Пространства имен следуют формату [DomainEntityName]. [AssemblyName]. [Purpose]. [RelatedPurpose], где DomainEntityName - это имя корневого бизнес-функционала, а AssemblyName - это функционально, поддерживающий бизнес-требование.