Как я могу сохранить / сохранить в синхронизации граф объектов в памяти с базой данных?

Question

Вопрос. Каков наилучший практический подход, позволяющий сохранять / поддерживать синхронизацию графа объектов jn-memory с базой данных?

Фон:

То есть у меня есть классы Node и Relationship, и приложение строит граф связанных объектов, используя эти классы.Там может быть 1000 узлов с различными отношениями между ними.Прикладная программа должна запрашивать структуру, поэтому подход в оперативной памяти, без сомнения, хорош для производительности (например, просмотрите граф из Узла X, чтобы найти корневых родителей)

Однако граф необходимо сохранить в базе данныхс таблицами NODES и RELATIONSHIPS.

Следовательно, каков наилучший практический подход для того, как сохранить / сохранить синхронизацию графа объектов jn-memory с базой данных?

К идеальным требованиям относятся:

• создание изменений в памяти и последующее «сохранение» впоследствии (обязательно)
• при сохранении применяются корректные обновления базы данных.Чтобы избежать попадания в какие-либо ограничения базы данных (обязательно)
• держите механизм персистентности отдельно от модели, чтобы упростить изменение слоя персистентности, если это необходимо, например, не просто оберните ADO.net DataRow в классы Node и Relationship (желательно)
• механизм для выполнения оптимистической блокировки (желательно)

Или это все накладные расходы для небольшого приложения, просто не стоящее, и я должен просто каждый раз попадать в базу данных длявсе?(при условии, что время отклика было приемлемым) [все равно хотелось бы избежать, если не слишком много дополнительных издержек, чтобы остаться несколько масштабируемой повторной производительности]

Answer 1

Я использую сущности самопроверки в Entity Framework 4. После загрузки сущностей в память функция StartTracking () ДОЛЖНА быть вызвана для каждой сущности. Затем вы можете изменить свой граф сущностей в памяти без каких-либо DB-операций. Когда вы закончите с изменениями, вы вызываете метод расширения контекста «ApplyChanges (rootOfEntityGraph)» и SaveChanges (). Так что ваши модификации сохраняются. Теперь вам нужно снова начать отслеживать все объекты на графике. Две подсказки / идеи, которые я использую в данный момент:

1.) Вызывать StartTracking () в начале для каждого объекта

Я использую интерфейс IWorkspace для абстрагирования ObjectContext (упрощает тестирование -> см. Реализацию OpenSource bbv.DomainDrivenDesign в sourceforge). Они также используют QueryableContext. Поэтому я создал еще одну конкретную реализацию Workspace и QueryableContext и перехватил процесс загрузки собственной реализацией IEnumerable. Когда потребитель рабочей области выполняет запрос, который он получает с помощью CreateQuery (), мой перехваченный объект IEnumerable регистрирует обработчик событий в ChangeTracker контекста. В этом обработчике событий я вызываю StartTracking () для каждой сущности, загруженной и добавленной в контекст (не работает, если вы загружаете объекты с помощью NoTrakcing, потому что в этом случае объекты не добавляются в контекст, а обработчик событий не будет быть уволенным). После перечисления в самодельном итераторе обработчик события в ObjectStateManager отменяется.

2.) Вызвать StartTracking () после ApplyChanges () / SaveChanges ()

В реализации рабочей области я запрашиваю контекстный ObjectStateManager для измененных сущностей, то есть:

var AddedEntities = this.context.ObjectStateManager.GetObjectStateEntries (EntityState.Added); -> аналогично для модифицированных объектов

приведите их к IObjectWithChangeTracker и вызовите метод AcceptChanges () для самой сущности. Это снова запустит средство отслеживания изменений объекта.

Для моего проекта у меня те же обязательные пункты, что и у вас. Я играл с EF 3.5 и не нашел удовлетворительного решения. Но новая способность самостоятельного отслеживания сущностей в EF 4, кажется, соответствует моим требованиям (насколько я исследовал функциональность).

Если вам интересно, я пришлю вам мой "шип" -проект.

У кого-нибудь есть альтернативное решение? Мой проект - это серверное приложение, которое хранит объекты в памяти для быстрых операций, в то время как изменения также должны быть сохранены (без обращения к БД). В некоторых точках кода графы объектов помечаются как удаленные / прекращенные и удаляются из контейнера в памяти. С помощью описанного выше решения я могу повторно использовать сгенерированную модель из EF, и мне больше не придется самому кодировать и оборачивать все объекты. Сгенерированный код для объектов самоконтроля возникает из шаблонов T4, которые можно очень легко адаптировать.

Большое спасибо за другие идеи / критику

Answer 2

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