Reputation: 4492
I have conversion tables I need to contain in memory for fast access. Until now I used a simple Hashtable
were the Key was the internal code, and the Value was an object holding the external code and other meta-data.
Now we need to have a reverse look-up, meaning to get the internal code based on the external code. I could only come up with the following options:
The container is being lazy-loaded, so options 1&2 usually won't perform under the worst-case scenario.
Thoughts anyone? Please tell me there's some efficient container I could use for that, which I missed!
* EDIT *
Being a GC'd framework, and accepting the fact I'd have to have two conversion arrays (Dictionaries), would the following lines of code actually mean I stored only one object on memory, and then two pointers for it, under two different hashed-cells?
Dictionary<K1,V> forward;
Dictionary<K2,V> reverse;
//...
void Add(V myObject)
{
// myObject being the BLL object
forward.Add(myObject.InternalCode, myObject);
reverse.Add(myObject.ExternalCode, myObject);
}
Itamar.
Upvotes: 0
Views: 90
Reputation: 146541
Build a custom collection class that has two internal hashtables (Dictionarys), one in each direction.
public BiHashTable<K, V>
{
private Dictionary<K, V> vals = new Dictionary<K, V>();
private Dictionary<V, K> keys = new Dictionary<V, K>();
public void Add(K key, V val)
{
vals.Add(key, val);
keys.Add(val, key);
}
public K this[v val] { get { return keys[val]; } }
public V this[K key] { get { return vals[key]; } }
// etc...
}
NOTE: This will be problematic is both K and V are the same type, you need a different formulation then...
Upvotes: 1
Reputation: 90525
I rather use two instances of Dictionary<TKey, TValue>
It favors code readability
Are you sure this dictionary is a performance bottleneck?
Upvotes: 0