Мое мнение таково, что EF с EDMX не готов к этим сценариям.Позвольте мне объяснить, почему:
- EDMX - это просто файл, используемый дизайнером.Во время выполнения вам нужно 3 файла XML (SSDL, MSL и CSDL), сгенерированных из файла EDMX.Эти файлы определяют модель, и они являются частью строки подключения объекта.
ObjectContext может работать только с объектами, указанными в этих файлах.- Стандартный подход - это один набор этих файлов для каждого соединения / контекста.Как только вы придерживаетесь стандартного подхода, вам очень трудно, потому что добавление таблицы означает изменение этих файлов XML (вы должны использовать подход, при котором эти файлы развертываются отдельно - подход по умолчанию использует эти файлы как ресурс внутри сборки доступа к данным).
- Iописано, как взломать EF, чтобы разрешить несколько файлов для одного подключения , но я не рекомендую это.
- Если вы создаете отдельный набор файлов метаданных, вам понадобится другой экземпляр контекста для работы с новымсущности (другая строка соединения), и эти два контекста не будут знать друг о друге и не смогут использовать сущности, сопоставленные в другой.
- Отображение - это только часть истории.Теперь вам нужен класс, который будет представлять вашу сущность в приложении!Если вы хотите, чтобы это «динамическое» поведение было только для разработки, то все в порядке, но добавление таблицы в модель во время выполнения или при перезагрузке приложения выглядит не лучшим способом - определение модели в инструменте ORM для времени разработки, а не для времени выполнения = вам нужноскомпилированная сборка с вашими новыми сущностями, и вам нужен код, который будет использовать эти новые сущности и ссылаться на вашу новую сборку.
DefiningQuery - это просто запрос к базе данных - вы можете использовать любую таблицу, присутствующую в вашей базе данных (или даже другую базу данных), потому что EF интересуется только набором результатов этого запроса.
С первым кодом у вас будет гораздо лучший опыт разработки.Код сначала не требует файла EDMX - он использует отображение, определенное кодом.Вам понадобится ваше приложение для сбора всех типов, полученных из EntityTypeConfiguration<> из предопределенных (или всех ссылочных) сборок при начальной загрузке.Все эти конфигурации будут добавлены в DbModelBuilder в OnModelCreation при создании первого экземпляра контекста.У вас будет контекст, который может легко использовать любую новую сущность после перезапуска приложения и развертывания новой сборки с сущностями.Тем не менее вам понадобится код для использования этой сущности.Вам придется создавать DbSets вручную, вместо того, чтобы выставлять их в качестве свойств в классе контекста, вызывая context.Set<EntityType>().Есть некоторые ошибки, когда вы делаете это сначала с кодом, потому что вы должны отключить проверку модели сущностей и воссоздание базы данных, и вы должны сами синхронизировать все.
Тем не менее мы обсуждаем сценарий, в котором вы развертываете новую сборку и когда приложениебудет перезапущен, он будет использовать сборку.Если вам требуется управление таблицами и «сущностями» из самого приложения, то это не сценарий для прямого использования ORM.Это относится к некоторым моделям метаданных / многопользовательским сценариям, и это делается совершенно по-другому, где ORM используется для некоторых общих абстрактных таблиц, а реальная сущность создается из метаданных, хранящихся в виде абстракции.