How do you avoid unboxing?

[David Young]

I'm using hashtables to transport data between layers in my app, but in so
doing, it seems almost impossible to avoid unboxing.

private static BusinessObject PackageBusinessObject(Hashtable myHashtable)
{
if(myHashtable!=null)
{
BusinessObject myBusinessObject = new BusinessObject();
myBusinessObject.Property1 = (string)myHashtable["Property1"];
myBusinessObject.Property2 = (int)myHashtable["Property2"];
myBusinessObject.Property3 = (DateTime)myHashtable["Property3"];
return myBusinessObject;
}
else
{
return null;
}
}

Obviously, we have to convert the object to a specific type, or else we'll
throw an exception.

Is the answer to use Convert?

ie:
myBusinessObject.Property1 = myHashtable["Property1"].ToString();
myBusinessObject.Property2 = Convert.ToInt32(myHashtable["Property2"]);
myBusinessObject.Property3 = Convert.ToDateTime(myHashtable["Property3"]);

Or does this unbox the object as well?

Dave

 

[Jon Skeet [C# MVP]]

I'm using hashtables to transport data between layers in my app, but in so
doing, it seems almost impossible to avoid unboxing.

Absolutely. The simple fact is, if you've put value types into a
hashtable, that *has* to involve boxing. If you get them out and
convert them back to value types, that *has* to involve unboxing.

Are you sure this is actually causing you a problem?

 

[Michael S]

Why don't you keep myBusinessObject in the hashtable instead of each
property?
If only few properties should be available in the HashTable, then define an
interface for this.

Regarding lists and dictionaries like HashTable and Session and the likes, I
live be the idiom of one object - one entry.

- Michael S

 

[David Young]

It's not causing any problems from a stack based vs. heap based instance is
concerned. My only concern was any performance degredation caused by the
unboxing.

Thanks,
Dave

 

[Jon Skeet [C# MVP]]

It's not causing any problems from a stack based vs. heap based instance is
concerned. My only concern was any performance degredation caused by the
unboxing.

That's what I was asking, really - are you sure that the performance
degredation is actually significant?

 

[David Young]

I actually expect it to be minimal (milliseconds), but I am always striving
to squeeze that extra ms out of every operation.

 

[Jon Skeet [C# MVP]]

I actually expect it to be minimal (milliseconds)

Oh, far smaller than that. A millisecond is *vast* amount of time.

but I am always striving to squeeze that extra ms out of every operation.

That way leads to unmaintainable code, unfortunately. There are far
more performance benefits to be gained in the long term from writing
readable code which is easily refactored than by micro-optimising
everything up front.

Write code in the most readable way, design your algorithms,
communications etc for performance, and leave micro-optimisation to the
rare situation where you find (with profiling) a performance bottleneck
is *actually* caused by implementation. Then just optimise that bit of
code, leaving the rest of your code as readable as ever.