Соглашения об именах .NET для решений с .NET Standard, .NET Core и .NET Framwork Projects

Я ничего не нашел в Интернете о принятых соглашениях об именах для решения .NET, которое содержит проекты .NET Standard, .NET Core и .NET Framework.

В моем случае в нашем проекте .NET Framwork было следующее соглашение:

[CompanyName].[TechnologyName].[Feature]

Теперь мы хотим перенести это на .NET Standard и .NET Core. Не все классы внутри функции работают со всеми из них, поэтому у нас есть проект .NET Standard, на который ссылается проект .NET Core. Затем на проект .NET Core ссылается проект .NET Framework. Как теперь назвать наши проекты.

Одним из решений было бы включить имя Standard или Core в пространство имен:

[CompanyName].Standard.[TechnologyName].[Feature]
[CompanyName].Core.[TechnologyName].[Feature]
[CompanyName].[TechnologyName].[Feature]

or

[CompanyName].[TechnologyName].[Feature].Standard
[CompanyName].[TechnologyName].[Feature].Core
[CompanyName].[TechnologyName].[Feature]

Но мы хотим знать, существует ли для этого глобальное соглашение об именах.


.net .net-core .net-standard naming
person Daniel Bretzigheimer    schedule 19.01.2017    source источник
comment
Я не уверен, что вам нужно название технологии как часть названия ваших проектов. Почему тип базовой структуры важен для наименования вашего проекта? Назовите свои материалы в соответствии с тем, что они делают для вас, с вашей точки зрения. Возможно, проект, работающий на .NET Core, является кроссплатформенным для вас, и в этом случае имена будут иметь вид [CompanyName].[Product].[Windows].[Feature], [CompanyName].[Product].[Cross-Platform].[Feature] и т. Д.   -  person nawfal    schedule 19.01.2017
comment
@nawfal: Одна из причин может заключаться в том, чтобы различать несколько вариантов проекта, ориентированных на разные базовые фреймворки.   -  person O. R. Mapper    schedule 19.01.2017
comment
@ O.R.Mapper Я думаю, что это будет крайне редкий сценарий, подумайте, к чему приведет дублирование кода. В любом случае такая ситуация возникает, когда имеет смысл назвать что-то вроде [CompanyName].[Product].[Framework].[Feature] или [CompanyName].[Product].[Feature].[Framework], потому что это так с точки зрения вашего продукта. Просто придерживайтесь одного из этих правил. В любом случае случай OP другой.   -  person nawfal    schedule 19.01.2017
comment
@nawfal: На самом деле, я думаю, что это очень распространенный сценарий. Для другой цели требуются разные версии зависимостей, поэтому часто можно использовать один файл проекта для каждой целевой платформы. Код не дублируется, так как одни и те же файлы включены во все проекты.   -  person O. R. Mapper    schedule 19.01.2017
comment
@ O.R.Mapper имеет смысл. Впрочем, вряд ли сталкивался с ситуацией. Я думаю, что со временем такие ограничения фреймворка становятся все больше и больше. Я все равно понимаю вашу точку зрения.   -  person nawfal    schedule 19.01.2017

Ответы (1)


arrow_upward
12
arrow_downward

Я думаю, что первоначальное руководство все еще в силе. Возьмите образец Microsoft.AspNetCore.Mvc. Это компания, продукт и все, что указано ниже. Версия .NET Standard или .NET Core должна поставляться под тем же именем, только упакованная для имени целевой платформы. Возьмите образец Newtonsoft.Json. Если поверхность / набор функций API изменится, сделайте критическое изменение версии или измените название продукта.

Пусть вас не смущают добавления Core в названиях продуктов Microsoft. Они решили сделать ASP.NET Core, .NET Core и EF Core новыми продуктами, чтобы избежать вводящих в заблуждение предположений о более высокой версии продукта: ASP.NET 5.

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

person Thomas    schedule 21.01.2017