В первой части мы упёрлись в стену из почти одинаковых блоков
if, которая растёт с каждым новым полем. Теперь зададим другой вопрос. Что если логика сравнения вообще не будет упоминать ни одного имени поля?У полей Go-структуры можно хранить метаданные через теги, те самые строки в обратных кавычках. GORM по тегу
gorm:"column:name" знает, в какую колонку базы ложится поле. JSON по тегу json:"name" знает имя в JSON. Это просто строки, которые рантайм умеет читать обратно через рефлексию.Обе стороны сравнения уже размечены. Модель базы знает свои колонки. Нужно лишь, чтобы входящий DTO объявил, какой колонке соответствует каждое его поле. Поэтому добавляем ещё один тег:
type DriverDriver struct {
Name string `json:"name" match:"name"`
Number string `json:"number" match:"number"`
ProfilePic *string `json:"profile_pic" match:"profile_pic"`
}Тег
match:"name" это весь контракт. Он говорит, что это поле надо сравнивать с колонкой базы по имени name. Правило маппера получается таким. Для каждого поля DTO с тегом match найди поле базы, у которого колонка gorm равна этому тегу, сравни их, и если различаются, запиши новое значение под именем колонки.Ни одно имя поля не зашито в логику. Определения структур сами становятся конфигурацией. Добавили поле и тег, оно автоматически попало в сравнение. Удалили, оно выпало. Сам маппер при этом не меняется. Вызов выглядит как одна строка на модель:
driverUpdates, err := mapper.CompareAndMap(driver.DriverDriver, dbUser)
metaUpdates, err := mapper.CompareAndMap(driver.DriverMeta, dbUser)
vehicleUpdates, _ := mapper.CompareAndMap(driver.Vehicle, dbVehicle)
Каждый вызов возвращает
map[string]any только из изменившихся колонок, и это ровно та форма, которую ждёт Updates() у GORM. Обратите внимание, второй и третий вызовы сравнивают совсем разные типы структур с разными таблицами одной и той же функцией.В следующей части разберём, как этот маппер устроен внутри.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека Go-разработчика
#GoDeep