On Wed, May 26, 2010 at 8:35 AM, Winston Pang <winstonp...@gmail.com> wrote: > Hi guys, > > This is more of a question of whether or not this sounds feasible and has > anyone seen anyone do this: > > Typically with most ASP.NET controls, lets take the ComboBox for an example, > it'll be like > > this.comboBox.DataSource = someList; > this.comboBox.DisplayMember = "Property1"; > this.comboBox.ValueMember = "Property2"; > > The client we're dealing with, has specifically told us to not "hard-code" > these property names, and to use reflection, through lambda expressions to > derive the property name. > > Firstly, do you think this will add a lot of overhead? I'm guessing it'll be > ok-ish, considering ASP.NET MVC uses it a lot.
No. > Also, has anyone seen people do it this way? No. > It this a stupid thing to do? I think it has it's merits to an extent, but > it sure doesn't seem common to me. Yes. Seems to me that no matter what you'll have some sort of dependency somewhere. Why not in the name of the field. Maybe it's worth considering the reason for the field changes. That said, I can see a potential reason for it, but I'd weigh that against the fact that I've never even considered doing it. Changing your development strategies purely on the basis of tools doesn't seem wise. > Cheers, > > Winston -- silky http://www.programmingbranch.com/
