Каков наилучший способ убедиться, что к базе данных привязан только один экземпляр модели ORM?
Эта проблема
У нас есть приложение, которое хранит иерархические данные в базе данных. Мы определили объект POCO, который представляет строку данных.
Проблема в том, что нам нужны определенные свойства, чтобы зависеть от детей элемента, а другие - от их предков. Например, если (великий) внучатый ребенок имеет неполное состояние, то неявно все его родители также являются неполными. Точно так же, если родитель имеет статус отключен, то все дети должны быть также неявно отключены.
На стороне базы данных все работает благодаря триггерам. Однако проблема, с которой мы столкнулись, заключается в синхронизации этих изменений с любыми объектами ORM в памяти, которые могли быть затронуты.
Вот почему мы думаем сделать все это, нам нужно убедиться, что в памяти есть только один экземпляр модели для каждой конкретной строки в базе данных. В этом суть всей проблемы.
В настоящее время мы делаем это с помощью триггеров в БД и одного гигантского хэш-набора слабых ссылок на объекты, привязанные к идентификатору базы данных для объектов ORM в памяти, но мы не уверены, что это правильный путь.
Первоначальный дизайн
Наш проект "новичка" начался с загрузки всех объектов из базы данных, которые быстро взорвали память, не говоря уже о том, что загрузка данных заняла много времени, которые могут фактически никогда не отображаться в пользовательском интерфейсе, поскольку пользователь может никогда не перейти к нему.
Попытка 2
Наша следующая попытка была расширена на первую, динамически загружая только уровни, необходимые для фактического отображения в пользовательском интерфейсе, что значительно ускорило загрузку, но теперь не позволяет опрашивать состояние иерархии без нескольких обращений к базе данных.
Попытка 2B
Как и выше, но мы добавили постоянные поля "неявного статуса", которые были обновлены с помощью триггеров в базе данных. Таким образом, если родитель был отключен, триггер обновил все дочерние элементы соответственно. Затем объекты модели просто обновляются с использованием последних значений из базы данных. Недостатком этого является размещение некоторой бизнес-логики на уровне модели и некоторых триггеров в базе данных, а также выполнение операций записи и чтения базы данных, необходимых для каждой операции.
Полностью динамичный
На этот раз мы попытались сделать наши модели "глупыми" и полностью удалили наш бизнес-уровень из кода, перенеся эту логику полностью в базу данных. Таким образом, было только единоличное владение бизнес-правилами. Кроме того, эти гарантированные плохие данные не могут быть вставлены в базу данных в первую очередь. Однако и здесь нам нужно было постоянно опрашивать базу данных на предмет "текущих" значений, то есть нужно было встроить некоторую логику, чтобы знать, какие объекты нужно обновить.
Полностью динамический с метаданными
Как и выше, но все вызовы записи в базу данных возвращали маркер обновления, который сообщал моделям, нужно ли им обновлять загруженных родителей или детей.
Я надеюсь получить отзывы от SO сообщества о том, как решить эту проблему.