C#: там какой-либо путь состоит в том, чтобы легко найти/обновить все ссылки на объект?
Я читал "Опытный C# Rockford Lhotka 2 008 Бизнес-объектов", где существует такая вещь как портал данных, который приятно краткие обзоры, куда данные прибывают из. При использовании DataPortal. Обновите (это), которое, как Вы могли бы предположить, сохраняет 'это' к базе данных, объект возвращается - сохраненный 'это' с любыми изменениями дб, сделанный к ней, например, метка времени.
Lhotka писал часто и очень небрежно, что необходимо удостовериться, что обновили все ссылки на старый объект к новому возвращенному объекту. Имеет смысл, но там простой способ найти все ссылки на старый объект и изменить их? Очевидно, GC отслеживает ссылки, действительно ли возможно насладиться этим?
Удачи
4 ответа
Сборщик мусора фактически не отслеживает ссылки на объекты. Вместо этого он вычисляет, какие объекты достижимы, начиная с глобальных объектов и объектов стека во время выполнения и выполняя некоторый вариант алгоритма «заливного заполнения».
Специально для вашей проблемы, почему бы просто не иметь прокси-сервер, содержащий ссылку на «реальный» объект? Таким образом, вам нужно обновлять только в одном месте.
Если вы передаете ссылки на объекты, и эти ссылки на объекты остаются неизменными, то любые изменения, внесенные в объект на уровне сохраняемости, будут мгновенно видимы для любых других потребителей объекта. Однако, если ваш объект пересекает границу службы, то сборки на каждой стороне объекта будут просматривать разные объекты, которые являются просто точными копиями. Кроме того, если вы сделали клоны объекта или создали анонимные типы, которые включают свойства исходного объекта, то их будет сложно отследить - и, конечно, для GC это новые объекты, которые не связаны с оригинальный объект.
Если у вас есть какой-то ключ или идентификатор в объекте, это становится проще. Ключ не обязательно должен быть идентификатором базы данных, это может быть идентификатор GUID, который создается новым при создании экземпляра объекта и не изменяется в течение всего жизненного цикла объекта (т. Е. Это свойство, которое имеет getter, но не setter) - поскольку это свойство, оно будет сохраняться через границы службы, поэтому ваш объект по-прежнему будет идентифицируемым. Затем вы можете использовать LINQ или даже старомодные циклы (неприятно!) Для перебора любой коллекции, которая, вероятно, будет содержать копию обновленного объекта, и если она будет найдена, вы можете затем объединить изменения обратно.
сказал это, я бы не подумал, что у вас плавает слишком много копий. ЕСЛИ вы это сделаете, то места, где находятся эти копии, должны быть очень локализованы.Обеспечение того, что ваш объект реализует INotifyPropertyChanged, также поможет распространять уведомления об изменениях, если вы держите список в одном месте, который затем прямо или косвенно привязан к нескольким другим точкам.
Для этого существуют профилирующие API , но не для общего пользования. Одно из возможных решений, которое я использовал сам, - это реализовать в базовом классе механизм отслеживания, в котором каждый экземпляр объекта добавляет WeakReference к себе в статическую коллекцию.
У меня это условно скомпилировано для сборок DEBUG, но, вероятно, было бы не лучшим решением полагаться на это в сборке релиза.
// simplified example
// do not use. performance would suck
abstract class MyCommonBaseClass {
static readonly List<WeakReference> instances = new List<WeakReference>();
protected MyCommonBaseClass() {
lock (instances) {
RemoveDeadOnes();
instances.Add(new WeakReference(this));
}
}
}
Нет простого способа сделать это напрямую Однако у Son of Strike есть такая возможность. Он позволяет вам вникать во все ссылки на объекты, отслеживаемые CLR, и смотреть, какие объекты ссылаются на какой-либо конкретный объект и т. Д.
Вот хороший учебник для изучения отладки CLR через SoS .