Question

Assume that I have the following object

public class MyClass
{
    public ReadOnlyDictionary<T, V> Dict
    {
        get
        {
            return createDictionary();
        }
    }
}

Assume that ReadOnlyDictionary is a read-only wrapper around Dictionary<T, V>.

The createDictionary method takes significant time to complete and returned dictionary is relatively large.

Obviously, I want to implement some sort of caching so I could reuse result of createDictionary but also I do not want to abuse garbage collector and use to much memory.

I thought of using WeakReference for the dictionary but not sure if this is best approach.

What would you recommend? How to properly handle result of a costly method that might be called multiple times?

UPDATE:

I am interested in an advice for a C# 2.0 library (single DLL, non-visual). The library might be used in a desktop of a web application.

UPDATE 2:

The question is relevant for read-only objects as well. I changed value of the property from Dictionary to ReadOnlyDictionary.

UPDATE 3:

The T is relatively simple type (string, for example). The V is a custom class. You might assume that an instance of V is costly to create. The dictionary might contain from 0 to couple of thousands elements.

The code assumed to be accessed from a single thread or from multiple threads with an external synchronization mechanism.

I am fine if the dictionary is GC-ed when no one uses it. I am trying to find a balance between time (I want to somehow cache the result of createDictionary) and memory expenses (I do not want to keep memory occupied longer than necessary).

Answer 1

There are four major mechanisms available for you (Lazy comes in 4.0, so it is no option)

1. lazy initialization
2. virtual proxy
3. ghost
4. value holder

each has it own advantages.

i suggest a value holder, which populates the dictionary on the first call of the GetValue
method of the holder. then you can use that value as long as you want to AND it is only
done once AND it is only done when in need.

for more information, see martin fowlers page