Properites vs. Fields, this time in databinding

Nikhil fires up the age old debate again… Data-binding to public fields... yes or no?

Comments (8)

  1. Matthew W. Jackson says:

    Public properties should almost always be used when exposing public instance data. The only place I’d use public fields are for static constant-like values (like Decimal.Zero), or for a class that’s not exposed publicly.

    That being said, there is often a need for a non-public classes to be used in data-binding. If it’s not exposed outside an assembly, there’s no big versioning issue with using fields to begin with and switching to properties later. While I suppose that allowing public fields to be used in data-binding may lead to many people exposing more public fields in public classes, it seems rather arbitrary that data binding only works with properties when properties look like fields everywhere else (except IL, of course).

  2. Chui Tey says:

    We are pitting one developer’s preference against another.

    Nikhil clearly states his personal preference that fields should not be public. C#’s designers did not take that view, and instead let the developers decide for themselves.

    Nikhil should allow binding, but introduce an FxCop rule to warn about this practice.

  3. Although I believe that fields should never be public (and thus not be bindable), I am also a Libertarian, which means that all developers should have the freedom to choose the "correct" implementation, along with the responsibility of dealing with the consequences of their free choice.

    Plus, if we continue putting intelligent rules into the language and tools, we will be reducing the requirements on developers and thus driving down our salaries. Keep the tools a step behind, and we can continue to foster a very lucrative developer elitism. I mean, just look at the FORTRAN guys.

  4. Data-Binding to Web Service Proxies

Skip to main content