Мне бы хотелось получить руководство по совместному использованию сущностей для нескольких DbContext с или найти альтернативное решение, которое решило бы одну и ту же задачу.
Мы используем EF Core для разработки системы DDDсостоит из нескольких логических модулей (Core, Foo, Bar, ...), каждый со своей DbContext / схемой и именем ConnectionString для одной и той же базы данных (но во многих случаях не требуется, чтобы все модули совместно использовалитот же дБ, если только в случае, описанном ниже).
Основной задачей было бы иметь возможность иметь модули, разработанные сторонними разработчиками (возможно, DotNetNuke?), которые управляют своими собственными схемами, не нарушая работу других поставщиков - при сохраненииабстракция, которую обеспечивает EF.
Базовый модуль предназначен для управления system Доменными проблемами (Diagnostics, Errors, Tenancy, Sessions, SessionOperations, Users, Permissions, UserSecurityProfiles, Roles, Media и т. Д.)
Другие модули предназначены для отдельных бизнес проблем, относящихся к конкретной области (например, один может быть дляStudent, School, Courses и др. Услуги и организации).
Практически во всех случаях не существует перекрестных связей между логическими доменами, поэтому каждый модуль представляет собой совершенно разные задачи, и аккуратно в этом отношении ... за исключением области пользователей и групп (насколько мы можем видеть).
Группы являются рекурсивными, и пользователи могут быть назначены на группы в различных ролях (Owner, Admin, ContactPerson, Member).User s может быть Enabled/Disabled и иметь элементы Name (Display, Given, Surname и т. Д.) И Email.
Это общая проблема, которую можно использовать во многих доменах,подходит для основного модуля.
Но другие логические модули и их отдельные DbContext могут иметь сущность, связанную с общим User.
В модуле SI (Информация об ученике), дляНапример, все Student с будут User с, поэтому могут наследоваться от User (или иметь свойство навигации).С другой стороны, в модуле CRM, например, не все Customer s будут User s, поэтому потребуется свойство навигации со значением NULL до User (я просто придумываю варианты использования здесь).
Отношение может быть
- хрупким (например, просто поле в объекте Student, содержащее идентификатор пользователя, который метод может использовать для получения связанного пользователя).
- navigable: например, у Student будет свойство навигации для основного пользователя.Преимущества в том, что могут быть разработаны запросы linq, использующие атрибуты пользователя.Например, можно выбрать всех учеников, которые являются включенными пользователями.Или найдите студента на основе его адреса электронной почты для входа в систему.
Мы попытались сделать следующее:
Мы попытались сделать StudentModelDescription в SIDbContext,это наследуется от UserModelDescription в модуле ядра CoreDbContext и настраивает схему определения модели так, чтобы она была «базовой», а не «SI», но, как и ожидалось, просто пытается удвоить Create Table и завершиться неудачей.
Мы не пытались добавить параметр CoreDbContext User к SIDbContext объекту Student, потому что, даже если он скомпилирован, SIDbContext не знал бы, извлекает ли ядро User (что выходит за рамки его моделиопределение).
Мы рассмотрели вопрос о том, чтобы наследовать SIDbContext от CoreDbContext, а затем игнорировать создание таблиц Core и отключить миграцию / создание модели (чтобы не пытаться-создать таблицы).Это был рекомендуемый курс в EF6, но это может свести на нет возможность для каждого поставщика иметь возможность добавлять / извлекать свои модули без координации в том же DbContext ...
По сути, у нас нет идей о том, как действоватьв продолжение этой базовой концепции (без каламбура), задаюсь вопросом, предоставляет ли EF Core новые возможности для решения такой проблемы.
Спасибо за понимание и время.