организуйте свой проект golang, а также свой код

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

Если вы не знакомы с моим предыдущим постом, вы можете перейти по ссылке ниже, чтобы понять функциональность. Нетрудно проверить взглядом, или, если у вас есть предыдущие знания о создании службы веб-API, вас могут обработать.



Создание службы веб-API RESTful с использованием Golang, chi и MySQL
создайте свой самый первый API REST с помощью go itnext.io



В этом уроке я покажу, как организовать проект. Организация вашего кода важна, потому что, когда вы хотите изменить некоторую логику своего предыдущего кода, хорошо структурированный проект может легко принять изменения, а также сэкономить время. Хотя есть противоречивые мнения о структурировании проекта, и я предпочитаю структуру из 4 слоев. Отсюда вы можете заменить или изменить что угодно.

project/
    model/
    repository/
    handler/
    driver/
    main.go

модели

Этот слой будет хранить всю структуру нашей модели и используется всеми остальными слоями. Теперь переместим нашу post структуру модели в файл models / post.go. Если у нас есть другая модель, например author, то эта модель также будет включена в этот слой. Мы также добавили файл error.go.

error.go содержит вашу недавно созданную ошибку. Подробности можно узнать здесь.

хранилище

Репозиторий отвечает за работу, связанную с базой данных, такую ​​как запросы, вставку / хранение или удаление. Здесь не реализована бизнес-логика.

Здесь я создаю repository.go внутри папки репозитория. Этот файл должен содержать весь интерфейс, связанный с вашим репозиторием. Если у нас есть дополнительный домен, например автор или что-то в этом роде, то сюда включается весь метод автора в интерфейсе.

Если вы заметили левую часть изображения выше, я создал папку с именем post. Мы реализуем наш интерфейс в post/post_mysql.go файле. Почему суффикс MySQL? Потому что, если у нас есть другая база данных для репозитория сообщений, например mongo или redis, мы включим post_mongo.go (как вы ни называете) и реализуем запросы, связанные с mongo.

post_mysql.go должен удовлетворять интерфейсу PostRepo. Если мы хотим добавить какой-либо дополнительный метод, мы должны включить его в интерфейс и реализовать в файле post_mysql.go.

обработчик

В основном папка обработчика может быть конфиденциальной для репозитория, поскольку этот уровень решает, какой уровень репозитория будет использовать. Здесь обрабатывается любой процесс. Этот уровень принимает запрос, вызывает уровень репозитория, удовлетворяет бизнес-процесс и отправляет ответ.

Уровень обработчика также содержит несколько реализаций протоколов, таких как RPC, REST и т. Д., Которые изолированы другой папкой.

Водитель

В нашей структуре уровень драйвера описывается всеми нашими подключениями к базе данных. Этот уровень отвечает за соединение с базой данных и отправку объекта соединения контроллеру.

Здесь мы будем использовать main.go вместо контроллера, поскольку наша служба имеет только один домен с операциями CRUD.

На сайте main.go мы предоставим все учетные данные и подключимся к базе данных. Мы читаем наши учетные данные БД в переменной среды, которая указана в файле docker-compose. Мы также держим здесь весь наш маршрут, но вы можете его изолировать.

Примеры проектов

Вы можете ознакомиться с образцом проекта здесь

https://github.com/s1s1ty/go-mysql-crud

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

В заключение

Вы можете узнать больше об этой теме по ссылкам ниже.

Все, что связано с этим постом, вы можете задать мне в разделе комментариев или linkedin.

Наконец, вы можете застрелить меня в разделе комментариев ниже, если заметите какую-либо ошибку, которую я сделал. Вы также можете прислать мне PR в моем репозитории GitHub.