Last month Jeff posted this blog entry about Properties vs. Public Variables and I mostly agreed with his thoughts, although I’m usually a use-a-property-to-encapsulate-a-variable person just for appearances.  I wish I had seen the update he put in the entry it would have saved me a few minutes of annoyance.

So I just stumbled across this lame rule today even though I’ve been databinding custom business objects for a long time, so I thought I would make a post just in case someone else runs into it and can’t figure out the issue right away.

Basically, I wanted a quick “data view” representation of a class that has a bunch of guids.  So I make a small ad-hoc class right there on my form (yeah bad form or whatever, so what it was a use once and throw away class, sometimes expediency is more valuable than design).  It goes a little something like this:

public class MyAdHocView
{
    public string ItemName;
    public string Quantity;
}

nice and simple.  So I databind to it expecting my grid to be all cool.  Well, the grid doesn’t *complain* about it, but it adds rows without visible values and I’m wondering wtf is wrong with it?  Quick look through the code shows that nothing appears to be wrong, I doublecheck all the grid creation code, it’s all good, so I think to myself “well, I don’t have it binding to properties…I wonder if that matters”.  I feel this would be stupid, but I want to rule it out so I apply the magical syntactic sugar (creating private lowercased variables and putting get/set blocks in the public ones) and viola! it works.   I see now that it is the expected and known behavior, but really, all that extra code for what exactly?  Meh.