Entity Framework - вставка объекта с несколькими моделями и базами данных

Мой домен разделен на несколько моделей Entity Framework. У меня есть несколько общих сущностей, которые охватывают несколько моделей (с именем Lookup), однако они заменены ссылками «using» с использованием методов, описанных в Работа с большими моделями в Entity Framework. Однако что делает мой случай немного более уникальным, так это то, что я также разделяю эти модели на несколько баз данных (по одной на модель).

У меня проблема со вставкой одного из моих общих объектов в мою общую базу данных. Это не срабатывает с ошибкой:

Член с идентификатором «Harmony.Members.FK_ResidentialAddress_ResidenceTypeLookup» не существует в коллекции метаданных.

Этот внешний ключ, на который он ссылается, не существует в «общей БД». Но я также не работаю с сущностью на другой стороне отношения (названной ResidentialAddress); у меня даже нет контекста, который содержал бы другой инициализированный объект (с именем MembersDb). Однако обе модели скомпилированы в одну сборку.

Свойства навигации, ведущие от поиска к ResidentialAddress, отсутствуют. Хотя есть свойство навигации в другом направлении (которое я не буду повторять - только в памяти).

Мой MetadataWorkspace для EntityConnection контекста CommonDb был явно инициализирован только SSDL / CSDL / MSL для данных, необходимых для этой базы данных. Я подтвердил, что в этом наборе данных схемы нет ссылок на внешний ключ.

var metaAssembly = typeof(CommonDb).Assembly;
var schemaResources = new string[]
{ 
    String.Format("res://{0}/Common.ssdl", metaAssembly.FullName), 
    String.Format("res://{0}/Common.csdl", metaAssembly.FullName), 
    String.Format("res://{0}/Common.mdl", metaAssembly.FullName), 
}
MetadataWorkspace metadata = new MetadataWorkspace(schemaResources, new []{ metaAssembly });
EntityConnection connection = new EntityConnection(metadata, myDatabaseConnection);

ВОЗМОЖНАЯ ПОДСКАЗКА: Это работает, когда я перехожу к сгенерированным классам и удаляю все атрибуты EdmRelationshipAttribute вместе с их парными EdmRelationshipNavigationPropertyAttribute из связанных моделей (MembersDb).

Ключевые вопросы:

  1. Так почему же Entity Framework пытается что-то сделать с отношениями, предназначенными для сущности, которая не входит в область видимости, и на нее не повлияет вставка записи !?

  2. Я счастлив, что сгенерированный код удаляет упомянутые выше атрибуты, но я все же хочу, чтобы свойства навигации остались. Как мне изменить CSDL для этого?

ПРИМЕЧАНИЕ. Сохранение «дочерних» моделей не является приоритетом, равно как и целостность их теперь перекрестных внешних ключей. Эти базы данных сохраняются с использованием SQL CE, но изначально они были созданы из одной главной базы данных SQL Server.


person Reddog    schedule 05.04.2011    source источник


Ответы (1)


Если каждая часть вашей модели записана в отдельную базу данных, то, возможно, файлы edmx не должны знать друг о друге (об объектах или отношениях с объектами, которые им не принадлежат).

Как насчет попытки один из следующих подходов:
(Чтобы получить одинаковые классы сущностей для каждой части, но сделать так, чтобы EF не обращал внимания на связи между ними.)

  1. Удалите "использование" из edmx + отмените автогенерацию и создайте классы самостоятельно.
  2. Удалите "использование" из edmx + измените шаблон t4, чтобы читать более одного edmx при создании классов.
  3. Скопируйте файлы edmx в сторону, чтобы у вас было два набора файлов edmx.
    3.a. Используйте набор # 1 для автоматического создания объектов.
    3.b. Измените набор № 2, удалив "использования" и используя для генерации классов репозитория (наборов объектов).

Сообщите мне, работает ли один из этих вариантов.

Удачи, Дэнни.

person Danny Varod    schedule 08.04.2011
comment
Дэнни, я остановился на чем-то похожем на вариант 2. Я создаю генератор (используя EdmGen2 в качестве стартера), который позволяет удалять свойства. Я приложил дополнительные усилия, чтобы вручную сгенерировать (я написал CodeDom) свойства навигации, которые я сначала удалил из CSDL. - person Reddog; 12.04.2011