Question: Recently I use data binding to speed up my development of C# winforms application. But I found that data binding is just useful when the control is Textbox or textare and text kind of controls. If things come to be radio button, image control or datagridview, it's hard for me to use data binding.  

 For example, it's hard for me to bind a group of radio button to a database field.  

 It's hard for me to pre-process the data in database and then bind to datagridview control(I know I can use view to do this, but it is not that convenient)  

 (another example: the vale in database is 1 and 0, I need to convert to female and male before binding datagridview) 

So I really want to know, most of you guys when will use data binding? And how will you use it ?

**EDIT:**
I know I can separate these things into different layers, but I do want to take advantage of the data binding, but while I use it, I found it is not that convenient, is there any other suffer from this ? 

**EDIT:**
but as far as i know the data binding is just like hardcode, it bind the control direct to the database field, and it's hard to make changes upon these user interface afterwards

Answer: 
The problem is that GenericTraversableTemplate is used twice: once for mutable collections (where its type parameter should be invariant), and once for immutable collections (where covariance is invariably king).

GenericTraversableTemplate's typechecks assuming either covariance or invariance for the A type parameter. However, when we inherit it in a mutable trait, we have to pick invariance. Conversely, we'd like covariance in an immutable subclass.

Since we can't abstract over the variance annotation (yet ;-)) in GenericTraversableTemplate, so that we could have instantiated it to either one depending on the subclass, we have to resort to casting (@uncheckVariance is essentially a kind-cast). For further reading, I recommend my dissertation (sorry ;-)) or our recent [bitrot paper](http://scholar.google.com/scholar?q="Fighting+bit+Rot+with+Types+(Experience+Report+Scala+Collections).")
I found another time where @uncheckedVariance is used -- the synthetic method that returns the default value for a parameter of an abstract type:

```
M:\>scala -Xprint:typer -e "class C { def p[T >: Null](t: T = null) = t }"
[[syntax trees at end of typer]]// Scala source: (virtual file)
package <empty> {
  final object Main extends java.lang.Object with ScalaObject {
    def this(): object Main = {
      Main.super.this();
      ()
    };
    def main(argv: Array[String]): Unit = {
      val args: Array[String] = argv;
      {
        final class $anon extends scala.AnyRef {
          def this(): anonymous class $anon = {
            $anon.super.this();
            ()
          };
          class C extends java.lang.Object with ScalaObject {
            <synthetic> def p$default$1[T >: Null <: Any]: Null @scala.annotation.unchecked.uncheckedVariance = null;
            def this(): this.C = {
              C.super.this();
              ()
            };
            def p[T >: Null <: Any](t: T = null): T = t
          }
        };
        {
          new $anon();
          ()
        }
      }
    }
  }

```