Entity Framework, широкая база данных Таблица руководства, порядок вставки

Question

У нас есть структура синхронизации, которая использует глобальную таблицу SyncEntity, чтобы отслеживать, какие объекты были обновлены в какое время, то есть у нас есть глобальная таблица со структурой, которая выглядит примерно так:

<dbo.SyncEntity> 
ID int 
EntityType int 
EntityGuid uniqueidentifier 

The EntityType является перечисление, который соответствует конкретной организации, так что мы знаем, в какой таблице искать для этого объекта. Все наши таблицы имеют идентификатор (PK) и идентификатор GUID.

Я создал ограничение внешнего ключа из разных таблиц Entity и EntityGuid в таблице SyncEntity.

Это прекрасно подходит для существующих данных, однако, когда мы используем EntityFramework для вставки новых данных, он не вставляет данные в «правильный» порядок, что приводит к ошибке, поскольку SyncEntity с требуемым EntityGuid еще не вставлен.

Я думаю, мы могли бы добавить свойство SyncEntity на всех наших объектах, однако я действительно не хочу загрязнять нашу модель домена этим свойством.

Итак, мой вопрос, есть ли в любом случае, чтобы определенные типы Entity были вставлены в качестве первых объектов? Или все равно отобразить отношение от Guid (по конкретному объекту) к EntityGuid (по SyncEntity) без свойства навигации.

Answer 1

Я вижу два способа потенциально облегчить эту проблему.

Во-первых, вы можете использовать события домена, чтобы узнать, что новый объект был создан и поднять событие, передав сам объект в качестве параметра, а затем разрешить этому событию создать новый файл SyncEntity, а затем сохранить его. Это заполнит ваш идентификатор, а затем вы сможете назначить его новому сущности, создающей взаимосвязь.

Во-вторых, вы можете переопределить SaveChanges метод DbContext смотреть на добавленных лиц, а затем создать новую запись для каждого из них, а затем присвоить новый SyncEntity Идентификаторы к объекту.

Answer 2

ПОЧЕМУ вы бы беспокоило EF что-то в этом роде?

Имейте запись SyncEntity, созданную с помощью триггера на таблицах. Законченный. EF не нужно беспокоиться об этом.

И это также полезно для прямого использования SQL.

EF - хороший инструмент - хотя и очень посредственный ORM. Но это не решение всего. Внутренняя логика БД, как и таблица протоколирования, должна обрабатываться в базе данных.