Dot Net What Not Posts

A common scenario is to have a button on a view that is bound to a command on the viewmodel. You can also have an ABCCommandCanExecute() method on the VM that tells the view whether or not the button can be clicked.

This is all fine until you want to ask the user to confirm the action that will be performed when they click the button. For example “Are you sure you want to reformat your hard disk, dial up all the people in your contact list and reformat their hard disks, and then destroy the world?” It’s kind of rude to do this without confirmation first.

The problem is that when you use WPF binding to bind the VM’s command method to the button’s Command property, you lose control over the execution process, and so can’t inject a message box into the flow.

When you use Linq to create a query against an entity framework model, a common scenario is to use the .Include() extension method to make sure that any child objects are also loaded. This is mainly useful when the results of the query are to be sent over WCF, where the client is disconnected from the source of the query, and so cannot go back to the database to pick up any child objects as needed.

This works fine for simple queries, but falls apart when you want to do anything clever, like joins or shaping.

I came across an innocent-looking Linq problem the other day that really had me baffled for some time.

It’s easiest explained using the ubiquitous Northwind database (although just about any other relational database would probably do). Suppose you want a list of customers with their orders. Pretty easy eh?

Erm no, it wasn’t!

Linq is great for grabbing entity objects. The code is simple, and you end up with known objects that you can use.

But, when you want to deal with anything slightly off the beaten track, it gets a bit harder. For example, if you have a Linq query that returns an anonymous type, you can easily manipulate it in the same code block.

Here I detail an early exploration into the world of anonymous types