Именование проектов в решении
Просто о NET | создано: 19.03.2022 | опубликовано: 19.03.2022 | обновлено: 13.01.2024 | просмотров: 2767 | всего комментариев: 1
Если вы разработчик, то точно знаете, что придумать название для проекта, метода, переменной или класса, на самом деле не такое уж простое дело. Особенно если вы работает в команде. В этой статье я опишу названия проектов (projects) для одного решении (solution), которые я обычно использую или стараюсь использовать.
Как назвать проект?
Если у вас есть всего один проект, и вы с ним работаете изо дня в день, то, по большому счету, для вас нет особой разницы как называются проекты. А если у вас десятки проектов, и вы пишите код, который может быть переиспользован в разных проектах, то соблюдение правил именования проектов, вам может существенно облегчить процесс поиск нужно файла, класса, функуционала. Во всяком случае, мне очень помогает в поиске возможности найти общие моменты для вынесения их в сборки (nuget). В любом случае, придерживаться определенного порядка никакого зла не принесет, а пользу вы точно почувствуете позже. Порядок должен быть во всём!
Чистая архитектура
Чистая архитектура (или Clean Architecture или CA) - на мой взгляд, очень полезная вещь, хотя бы потому, что заставляет разработчика правильно выстраивать зависимости в проектах для одного решения. Это помогает избежать рекурсивной зависимости в классах и модулях. Неправильные связи, порой, могут привести к невозможности реализации какого-нибудь нового функуционала.
В последние время модная тенденция именовать проекты в соответствии с подходом Clean Architecture сводится на "нет", потому что это не чёткая инструкция по разработки ПО, а всего лишь абстрактная модель, которой надо придерживаться при разработки ПО. Однако, если инструкции не очень чёткие, то их каждый понимает по-своему. Неудивительно, что именуют все по правилам CA, а то что в них лежит может существенно разнится с тем, что каждый вкладывает в эти понятия. Я использую подход, описанный CA, но названия обычно использую немного другие, чтобы точно понимать "что", "почему" и "где".
Напомню, как выглядит Clean Architecture в формате картинки у ее основателя Роберта Мартина:
Правда, всё сразу понятно?
Пример
Если посмотреть на картинку, то сразу понятно, что ничего не понятно или почти ничего. Но надо понимать, что именование проектов очень сильно влияет на namespace в C#, потому что имено на названиях проектов он (namespace) и строится. Итак, как и почему я именую проекты в своих решениях.
Для начала namespace для Solution. Например, Calabonga.Catalog.sln, структуту можно посмотреть в github.
- Назавание solution начинается с Calabonga.
Calabonga - это название организации, своего рода уникальный идентификатор компании или разработчика, что бы чётко разделить все существуюшие сборки от моих. - Название через точку включает в себя продукт, например, Catalog.
Обычно, я использую не более двух слов в название продукта, который будет реализован в решении.
Далее, после точки следует название проекта, сборки, если хотите, которая определяет тип взаимодействия между проектами.
Теперь немного подробнее о том, как устроено решение и какие проекты в нем для чего служат.
- Сборка с примитивами Calabonga.Catalog.Core.
Другие варианты названий для этого проекта: .Primitives, .Contracts, .Interfaces.
В этом проекте находятся простые примитивы, но при это общие и публичные, которые используются во всех проектах системы или почти во всех. Например, перечисления (enum), интерфейсы приложения (типа IProfileService) и так далее.
Чаще всего я использовал .Core, но когда вышел NET Core стал использовать .Contracts. - Сборка с сущностями Calabonga.Catalog.Models.
Другие варианты названий для этого проекта: .Entities, .Domain.
В этом проекте находятся те классы, которые которые хранятся в БД. Это если по-простому.
Чаще всего я использую .Entities. - Сборка для доступа к хранилищу данных Calabonga.Catalog.Data.
Другие варианты названий для этого проекта: .Application, .Database, .UseCases, .Infrastructure. Кажется совсем неочевидные названия, но это действительно так. В противном случае, придется разбивать на большее количество сборок (например, .Data и .Application, и это иногда оправдано). В этом проекте находятся классы, которые обслуживают .Entities на предмет чтения из хранилища, манипуляции данными и сохранения данных обратно в хранилище. Опять же, если по-простому.
Чаще всего я использую .Data. - Сборка представления Calabonga.Catalog.Web.
Другие варианты названий для этого проекта: .API, .WPF, .Client, .Blazor, .MVC, .Host.
Этом проект являет собой ничто иное как клиентское приложение, где находятся формы представления, классы их обслуживаюшие и прочие причиндалы, без который это приложение не будет работать. И снова, это если говорить простыми формулировками.
Чаще всего я использую .Web.
Заключение
Правила - упрощают жизнь, хотя правила бывают разные. Возьмите, например, договоренности в ASP.NET MVC проекте, или даже правила дорожного движения. Кто живет не по правилам - рискует попасть в неприятную ситуацию. "Расставлять всё по полочкам" - хороший тон. Порядок в голове - порядок в коде. Пишите правильный код!
Комментарии к статье (1)
Благодарю за полезную и краткую статью