C# – Passing Anonymous Type to a Bound Control

Generally speaking, I'm fairly opposed to the use of anonymous types in real-world code (except in LINQ and some other specific scenarios), but I'm looking right now at a situation where I need to bind an ASP GridView control with a collection of tuple values and they're looking pretty tempting.

Basically, I need to show a list of proprietary accounts that are associated with different computer names. I don't currently have a type that contains those two properties because I don't use them together like this anywhere else.

What I would normally do in a situation like this is just create a new class that has the properties, set the ItemType on the GridView to reference that type, then build objects of that type in my Select method (I use ObjectDataSource much of the time). But I'm thinking now that there's really no benefit to throwing in that extra class, since no matter what it's getting bound via reflection.

Is there any reason to shy away from using anonymous types in data-binding situations like this?

I'd accept anything: performance, readability, maintainability, principle, or whatever else you can throw at me. But the only disadvantage I can think of is if I wanted to use the Item property to use Intellisense for my data-binding, but in this particular case I have no use for anything more than BoundFields. Of course, this is all based on the assumption that it even works, admittedly I haven't tried it yet with anonymous types, so it might just not be supported for one reason or another.

Best Answer

And your assumption about it not being statically typed is wrong too.

From the documentation:

Anonymous types are class types that derive directly from object, and that cannot be cast to any type except object. The compiler provides a name for each anonymous type, although your application cannot access it. From the perspective of the common language runtime, an anonymous type is no different from any other reference type.

Related Solutions

Pattern for Select Case on Object Type in C#

Create a data structure, such as a dictionary, which uses the type as the key and the value is the chart property. If you have multiple chart properties associated with a given type, then the value could be a ChartProperties object. So you have something like this:

ChartProperties chartProp;
if (propertiesMap.containsKey(currentFilter.getType()){
  chartProp = propertiesMap(currentFilter.getType());
}

I would make the properties map a subclass of a dictionary and then put the above code in a method on that class.

C# – Assert equality in mstest when types may differ

Assert.AreEqual is basically just sugar for Assert.IsTrue(object.Equals(...)). If there isn't a known comparison operator for the two argument types, they'll compare false.

dynamic is pretty smart about this, so, for example, (dynamic)(int)1 == (decimal)1.0 evaluates to true. That only works if you use the == operator, though; it won't work if you try to use object.Equals, Assert.AreEqual, ((dynamic)x).Equals(...) or anything similar. Simply casting to dynamic won't work, you need to actually use its == operator. The good news is, the dynamic == allows any operand, which means you can get this to compile in a general-purpose assertion; if the comparison is invalid (e.g. comparing int to string, then it will fail at runtime with a RuntimeBinderException.

The next best thing, if you know they're going to be numeric types, would be to cast them all to Decimal or Double, although note that if you use Double you'll have to take into account the possibility of floating-point rounding error, and you should define equality based on some threshold, typically a multiple of Double.Epsilon. Decimal is a lot simpler unless you know for certain that you'll be dealing with floating point.

I don't think that you really have a lot of other choices. I personally would not recommend string conversion because lots of classes don't override ToString, so you end up comparing two instances of something like System.Collections.Generic.List``1[System.Int32], and your assertion declares that these are equal because they have the same string representation when in fact they are not only different instances but contain completely different elements. So don't do that. String coercion can easily mask serious errors in your tests. Stick to non-lossy, all-or-nothing conversions as above.

Best Answer

Related Solutions

Pattern for Select Case on Object Type in C#

C# – Assert equality in mstest when types may differ

Related Topic