I won't bind with you! you are nothing but a lousy field
Nikhilk relaunched an old debate last week. Data-binding to public fields... yes or no?, in principle i agree with the decision of not binding to public fields, but as Otto von Bismarck once said:
"When a man says he approves of something in principle, it means he hasn't the slightest intention of putting it into practice."
I wouldn't go so far, but a nice quote allways looks good. :-)
When all you want is to show one of two fields, it's easy to agree with Scott, it seems an awfull trouble to go, just to show some fields (i already felt that pain, and it was not one or two fields, but more on that later).
But properties are the way go, more clean and more OO.
My gripe is with WS proxy generator, i want to bind to public fields, because the proxy generator only generates public fields, which is a royal pain in the a**.
Picture an application that is written with SOA principles, dozens and dozens of exposed services. Best practices applied, no internal data is exposed. All data that is exposed, through Data Transfer Objects (DTO) generated with Assemblers.
Now imagine that you have another application, that has very little logic on it's own, and all it has to do is to drive the UI to the previously refered application through service calls. Writing the assemblers and the DTO's is already a large task by itself, by not allowing us to bind to the proxies, i would estimate that with the added effort to "manually bind", the overall effort is largely inflated.. (This has been my pain for the last months).
By not generating properties for the proxy, we have some choices:
- Write some helpers with similar syntax and semantics of DataBind.Eval, but that works with reflection in order to work with public fields.
- Write service agents, that transform the proxies into classes (DTO's or Domain Objects) that are are first class .NET citizens to be databinded. This seems not only silly, but would be compared to killing flies with a cannon.
- Extend the proxy generator, so that properties are generated. (not possible until whidbey is released).
- Write your own proxy generator (i actually considered this), but this was an effort that hardly could be justified.
- Write a proxy for the proxy,that during runtime would fake properties for the proxy. (perhaps using this, this would robably fall in the categories of nice hacks and probably in the category of alien artifacts, but it certainly would be a stupid thing (TM),and a big waste of efforts)
Looking in retrospective, i can only cry with all the hours i've wasted by the fact that public fields are not bindable, only because ws proxy generator doesn't generate proxies with propertyes. Anyway 2 wrongs don't make a right. What i really want, is proxies with properties. Fortunately whidbey proxy generator will generate properties, and in the meanwhile we seem to have 2 choices:
While this wouldn't be a problem for me, it has some logistical headaches on it's own. This would cause a non standard dev environment, which is something i can't afford for this probject. Oh well, "manual binding" will continue, as well as swearing and cursing the guy who made the decision not to generate properties. :-)