Я пытаюсь сделать что-то с помощью EF, что, на мой взгляд, должно быть простым, но я не могу понять, как именно это сделать.
Допустим, у нас есть основное веб-приложение ASP.NET, данные которого хранятся в схеме dbo в нашей базе данных. Затем мы хотим добавить дополнительный модуль, данные которого хранятся в схеме opt, которую мы можем включить в зависимости от некоторых бизнес-потребностей.
Дополнительному модулю потребуются данные из основной схемы - это расширение функциональности, найденной там. Чтобы сделать это безболезненным, было бы неплохо иметь беспроблемный опыт использования LINQ.
Рабочий прототип, который у меня есть в настоящее время, является отношением наследования OptionalDataContext : CoreDataContext. CoreDataContext используется для доступа и изменения существующих данных.
Допустим, я хочу просто добавить одну таблицу в схему opt: DbSet<OptionalClass> OptionalClasses. Он получает свойство OptionalDataContext. Необязательный класс выглядит как
[Table(Name="OptionalClasses", Schema="opt")]
OptionalClass {
public int Id {get; set;}
public string OptionalData {get; set;}
public virtual CoreAppClass CoreData {Get; set}
}
, в котором виртуальное свойство указывает на таблицу dbo.CoreAppClasses.
Теперь у нас после хакерского запуска настройка позволяет моему единому контексту свободно выполнять соединения и запросы LINQ по всей схеме. Если CoreAppClass, в свою очередь, имеет виртуальные свойства, я могу получить к ним доступ с помощью цепочек операторов Include. Это здорово.
Проблема, с которой я сталкиваюсь, заключается в том, что когда я создаю исходную миграцию дополнительного приложения, он пытается создать все существующие таблицы в схеме dbo, но они уже существуют.
Я могу использовать -IgnoreChanges, чтобы сгенерировать первую миграцию после комментирования одного DbSet необязательного контекста, затем добавить свой дополнительный DbSet и продолжить оттуда, но это означает, что когда кто-то обновляет схему базы данных основного приложения, нам потребуется запустить то, что по сути является миграцией слиянием, в дополнительном приложении.
Есть ли простое решение сделать так, чтобы при добавлении миграций в основном использовалась команда -IgnoreChanges для основной части только этого нового OptionalDataContext?
Использование modelbuilder.Ignore () для каждого отдельного свойства ядра нежизнеспособно - это просто дополнительные проблемы обслуживания. Я хочу установить некоторую конфигурацию, чтобы эти миграции просто обновляли моментальный снимок модели EF для любых изменений в таблицах dbo, но создавали миграции для всех изменений opt.