WeakReference understanding

Question

I want to create the dictionary of all the ViewModels.

   public static Dictionary<string, WeakReference> vmCollection = new Dictionary<string, WeakReference>();

Adding it like this

 vmCollection.Add(name, new WeakReference(viewModel));

And calling the required method like this..

((vmCollection[viewModel].Target) as BaseViewModel).NewMessage(message);

Do I need maintain it as a WeakReference? What could be the consequences if I don't maintain it as a WeakReference.

don't forget to check if the object is alive before accessing it - IsAlive on the WeakReference — Ventsyslav Raikov, Jun 07 '12 at 08:50
If you are looking to implement a messaging type solution then have you looked at the EventAggregator in Prism? — slugster, Jun 07 '12 at 11:04
Thanks slugster.I want to implement it on my own to avoid any kind of dependncy... — Learner, Jun 08 '12 at 04:45

score 32 · Accepted Answer · edited Apr 09 '20 at 07:08

The only consequence of not using a WeakReference is that the reference in your dictionary will prevent the View Model instances from being garbage collected. A WeakReference allows garbage collection (assuming there are no other solid references elsewhere).

An item becomes eligible for garbage collection when it has no references to it. WeakReference does not create a "countable" reference, thus you can keep a sort-of-reference to it, but still let it be eligible if your WeakReference is the only thing left looking at it.

Whether you need it or not really depends on what sort of life-cycle your View Models have. If they need disposing or otherwise "letting go of", then you may need to use WeakReference or expose a way to remove the reference from the dictionary instead.

As I mention in the comments. I tend to err away from using WeakReference as opposed to handling the life-cycle of the relevant objects explicitly. That said, they are useful when you simply don't have visibility of the life-cycle at the relevant points. I think in your situation, you should have the necessary visibility, as these are all likely in the UI layer, and thus should try to not use them.

Here is a resource on the topic:

Weak References MSDN article

Guidelines extract from the above MSDN link:

Use long weak references only when necessary as the state of the object is unpredictable after finalization.

Avoid using weak references to small objects because the pointer itself may be as large or larger.

Avoid using weak references as an automatic solution to memory management problems. Instead, develop an effective caching policy for handling your application's objects.

I believe the last guideline point applies to your situation.

Thanks a lot Adam. will it be any sort of OverHead if on the safer side i use it? — Learner, Jun 07 '12 at 08:42
@RaoBHavik The overhead will be the cost of the `WeakReference` object instance itself, and the need to constantly check if the object that is referenced is still usable (obviously, it could have been collected since you last used it). I would always err away from using them as opposed to handling the life-cycle of objects explicitly, but sometimes you just don't have visibility of the life-cycle so they can prove useful. I think in your case you should have visibility so should likely try to not use them. — Adam Houldsworth, Jun 07 '12 at 08:43

score 0 · Answer 2 · answered Oct 29 '18 at 11:10

I took a slightly different approach.

For this example, I only have a single instance, but I'm sure it's fairly easily extendable for multiple instances...

So, on my class I create the following Action (it could be a Func if you need something returned). For my example, I'm just pushing an Exception around:

private  static Action<Exception> StaticAccessorToInstanceMethod { get; set; }

And the instance method I want to call is:

public void HandleExceptionDetails(Exception e)
{
    // Content of the method on the instance
}

I then have this in my constructor:

StaticAccessorToInstanceMethod = this.HandleExceptionDetails;

And the following in the destructor:

StaticAccessorToInstanceMethod = null;

(If you're dealing with multiple instances, then the constructor and destructor code would be a bit different).

Then the static method simply calls the instance method:

public static void HandleGeneralException(Exception ex)
{    
     StaticAccessorToInstanceMethod(result);
}

I've left out defensive logic.

WeakReference understanding

2 Answers2

Linked