RiggsHill Software

Binding Entities to Forms controls - easily done but not easily divined.

The naive would hook a LinQ query to the BindingSource's DataSource - and would be rewarded with a functional binding - most of the time.  In fact for read only lists of things this may be acceptable (adding/deleting objects causes inconsitencies in the ObjectManager).  One piece of advice I ran across is to not use this type of binding because every time the BindingSource moves to a different record it rexecutes the query (not confirmed by my testing but it may be true) which could be handy in a highly concurrent environment.

After much gnashing and googling I came across the "proper" way to do this (actually it's in book: "Programming Entity Framework" - O'Reilly"):

ObjectQuery<User> query;
...
query = ( from var in m_model.Users
          orderby var.sortorder, var.name
          select var
          ) as ObjectQuery<User>;
userBindingSource.DataSOurce = query;

As long as you cast the LinQ query to a ObjectQuery<T>, the BindingSource coordinates everything properly.

 

Typing: The query is run on the EntitySet while the ObjectQuery<T> is typed to the underlying object.

Lambda expressions and statements: In the context of Forms programming, is there an advantage over anonymous methods? The lambda form is certainly more succinct and (with a bit of practice) simpler to read. Examples: Some simple callbacks as expressions:

// pop a message
button.Click += ( sender, args ) => MessageBox.Show( "Click" );
// increment a numeric updn
button.Click += ( sender, args ) => number.Value = number.Value + 1;

Here's the same things as anonymous methods:

button.Click += delegate( object sender, EventArgs e ) { MessageBox.Show( "Click" ); }
button.Click += delegate( object sender, EventArgs e ) { number.Value = number.Value + 1; }

Slightly more complex callback as a lambda statement (note the enclosing {}):

this.FormClosing += ( sender, args ) => {
    if ( MessageBox.Show( "Really?", "Quit?", MessageBoxButtons.OKCancel ) != DialogResult.OK )
        args.Cancel = true;
};

And as an anonymous method:

button.Click += delegate( object sender, FormClosingEventArgs args ) {
    if ( MessageBox.Show( "Really?", "Quit?", MessageBoxButtons.OKCancel ) != DialogResult.OK )
        args.Cancel = true;
};

In this context (simple examples) there's very little difference (especially since they apparently compile to nearly identical code) other than brevity. One thing I've found is that my event handlers and EventArgs derivatives tend to have really long names - the brevity of the lambda syntax is very appealing from that standpoint.