Если вы используете интерфейсы для подсчета ссылок, а затем вставляете их в какую-то коллекцию, то у вас всегда будет ссылка на них. Если ваша цель - «сбор мусора», то вам нужен только один или другой, но вы, безусловно, можете использовать оба при необходимости.
То, что вы действительно хотите, это кеш бизнес-объекта. Для этого вы захотите использовать одну из новых универсальных коллекций TDictionary . Что вы можете сделать, это иметь TDictionary из коллекций TDictionary, по одному TDictionary для каждого из ваших типов объектов. Вы можете указать свой основной TDictionary на перечислении или, возможно, даже на типе самого объекта (я не пробовал, но это может сработать.) Если вы используете GUID для своих уникальных идентификаторов, вы можете поместить их все в один TDictionary.
Реализуйте каждый из ваших бизнес-объектов с помощью интерфейса. Вам не нужно использовать Smart Pointers, так как вы проектируете свои бизнес-объекты и можете их потомствовать из TInterfacedObject. Затем ссылаться на него можно только по интерфейсу, чтобы он мог быть подсчитан.
Если вы хотите, чтобы срок действия вашего кеша истек, вам понадобится временная метка для ваших объектов, которая обновляется каждый раз, когда объект извлекается из кеша. Затем, когда размер кеша превысит определенный размер, вы можете удалить все, что старше определенной временной отметки. Конечно, для этого требуется пройти весь кеш.
Поскольку вы комбинируете интерфейсы и коллекцию, то, если у вас есть ссылка на объект (через его интерфейс), и он удаляется во время очистки кэша, тогда объект будет оставаться живым, пока ссылка не исчезнет. Это обеспечивает вам дополнительную безопасность. Конечно, если вы все еще используете ссылку, это означает, что вы сохранили ссылку в течение длительного времени, не извлекая ее из кэша. В этом случае вы можете обновить отметку времени, когда вы читаете или записываете свойства тоже. , , Многое зависит от того, как вы будете использовать бизнес-объекты.
Что касается повторной выборки, вы можете сделать это, только если объект извлекается из кэша, который старше, чем предел повторной выборки. Таким образом, если его обрезать перед повторным использованием, вы не тратите время на поездки в базу данных.
Вы можете подумать о том, чтобы иметь в последний раз измененное время в каждой таблице. Затем, когда вы получаете объект из кэша, вы просто сравниваете время в памяти с временем в базе данных. Если объект был изменен с момента его последнего извлечения, вы можете обновить его.
Я бы ограничил обновление объектов только тогда, когда они извлекаются из кэша. Таким образом, вы с меньшей вероятностью измените объект, пока он используется. Если вы находитесь в процессе чтения данных из объекта во время его изменения, это может привести к действительно странному поведению. Есть несколько способов справиться с этим, в зависимости от того, как вы используете вещи.
Слово предупреждения об использовании интерфейсов, у вас не должно быть и ссылки на объекты, и интерфейсы на один и тот же объект. Это может вызвать проблемы со счетчиком ссылок и привести к освобождению объектов, пока у вас есть ссылка на объект.
Я уверен, что будут какие-то отзывы по этому поводу, поэтому выберите то, что звучит как лучшее решение для вас. , , .
Конечно, теперь, когда я написал все это, я предлагаю вам взглянуть на какую-то инфраструктуру бизнес-объектов. RemObjects имеет хороший фреймворк, и я уверен, что есть и другие.