Стас ВыщепанПрямо в статье есть пример как делать джоин разных источников в приложении. Делаете сервис, куда упаковываете эту логику и мигрируете если надо. Я не рекомендую прятать это внутрь ef.
Но непонятно зачем.
Модульный монолит почти нет смысла пилить на сервисы, кроме выделения отдельной системы с отд
реализация сервиса меняется в зависимости от источника данных, хотя логика джойна сохраняется. я же говорю про логику джойна, выраженную в виде кода, сохраняющегося при изменении источника данных
С К
Ivan VoyagerНедавно написал новую систему миграций в своем фреймворке, там для 1 бд и тоже с разными контекстами (модулями), у меня упор на проиизводительность, поэтому фреймворк более низкоуровневый и для десктопа). Стас, можешь сказать, как в EF и в твоем подходе решается порядок миграций разных модулей, когд
в статье описана такая картина:
- модули собираются в одну модель EF
- миграции генерируются по полной модели из всех модулей
Модулей много, но модель одна и никаких зависимостей нет. Все внутри разруливает сам EF.
Порядок сборки полной модели задается порядком загрузи модулей.
В следующих статьях будет описание кодогенератора для этого дела, а п в этой просто строкой вбито в DesignTimeFactory для EF
I то есть там идеальная картина в вакууме, когда модули не зависят от других, верно? но ведь хотя бы есть какие-то базовые миграции для таблиц core, которые могут использовать модули? или прям реально у всех свои таблицы и никак данные не пересекаются? идеальный мир) Порядок сборки полной модели задается порядком загрузи модулей. - то есть миграции будут применяться по порядку загрузки?) это детерменированный механизм?)С нет. Прочитайте статью внимательно, посмотрите код Там есть есть модуль CustomerOrders, который зависит от Customer.Entities и Order.Entities Более того CustomerOrders еще и внешний ключ между сущностями добавляет в модель. Но все они собираются в итоге в одну модель и миграции создаются по полной моделиI
С давайте сначала Как работают миграции в EFCore: - У вас есть модель, которая собирается как-то в коде - У вас в коде лежит снэпшот предыдущей модели - Когда вы делаете dotnet migrations add запускается ваше приложение, из него достается актуальная модель, загружается снэпшот и делается их дифф. Дифф сохраняется в качестве новой миграции - каждая миграция - просто класс с методами Up и Down. Up приводит схему от предыдущего состония к текущиему, а Down наоборот. - миграции выполняются последовательно, отсортированные по строке в атрибуте Migration Одна модель - один набор миграций, которые выполняются последоватеьно. Никаких зависимостей между ними нет, кроме последователньости. Я описал как модель собирать по кускам из модулей. Итоговая модель зависит от порядка модулей. Миграции генерируются всегда по полной модели - всем модулями заданным в нужном порядке.I С
С I