с DbContext и миграциями? Я после спринга смотрю на это и чето не втыкаю почему так и в целом
Нашел у кого спрашивать) Что ты там не понимаешь?
Сам подход взаимодействия через контекст и миграции, в спринге я просто имплементировал JpaRepository и через реализацию сервиса спокойно взаимодействовал с БД, никаких миграций не было, все явно помечалось аннотациями по типу Entity, отношения между таблицами тоже как-то более явно указаны были через те же аннотации Знаю, что в спринге тоже можно миграции делать, через Flyway вроде, но там все на sql чистом и работает как-то отдельно вроде, что мне показалось более удобным
Ну dbcontext это просто интерфейс который представляет твою бд. Указывать связи ты можешь несколькими вариантами. Не явно, тут просто ef сам сгенерит в зависимости от навигаций внутри entity Явно через атрибуты Явно через конфиг dbcontext'a Явно через наследование IEntityTypeConfiguration для каждой сущности Про миграции, эмммм, как это в спринге нет миграций? А если данные поменять надо? Там это все неявно под капотом что ли накатывается?
По поводу последнего: абсолютно хз, поясняю, как я делал: Подключил в мавене Spring Data JPA и драйвер условного постгреса Описал классы, которые являются моделями Написал репозитории (UserRepo implements JpaRepostitory<Integer, User> {}) Написал сервисы, которые подключают в себя соответствующий репозиторий и используют его для работы с бд, к примеру: private UserRepo userRepo; и в методах используются какие-нибудь методы по типу userRepo.delete() и т.п., которые по дефолту есть в JpaRepository Также можно в репозиториях объявить какой нибудь метод, например findByUsername и спринг сам поймет, че должен делать этот метод, по его названию, т.е. функционал писать не надо, просто в интерфейсе объявить с правильным названием
Обсуждают сегодня