такой кейс: модели, в зависимости от типа, по-разному работают с репозиторием, через разные методы (напрммер - по-разному хранятся, где-то как одна запись в таблице, где-то как целая таблица, говоря словами реляционных бд).
Вопрос, где хранить логику работы модели с бд? Я планировал создать по классу под каждый тип модели, в него передавать интерфейс репозитория и решать, каким именно методом оперировать.
Проблема: по правилам чистой архитектуры, внутренние слои не должны знать о внешних.
В твоем примере я не понял, каким образом ты узнаешь про внешний слой, если твои "классы" принимают параметром интерфейс репозитория?
Логику работы модели с БД реализуют в репозитории. Методы репозитория могут принимать на вход модели и могут возвращать модели, соответственно репозиторий знает все о устройстве моделей. Имплементация репозитория находится в слое инфраструктуры, поэтому он может оперировать моделями не нарушая направления зависимостей.
SaveData(db *sql.DB, data *DataClass) OpenDataByID(db *sql.DB, data *DataClass) и т.д. Словосочетание "чистая архитектура" нужно знать только лишь для того, чтобы идиоты на собеседовании услышали от вас то, что они хотят услышать. К программированию это ни какого отношения не имеет
Обсуждают сегодня