The x:Class declaration tells the window where the codebehind is stored (Project IB_MVVM, file MainWindow.xaml.cs). The two namespace declarations are used by WPF and are always included. WindowStartupLocation does what it looks like it does. The expander is just there because it looks so darned cute.

The boldfaced lines in the XAML are the story. They tell the UI engine to bind to data stored in an object called custs for the grid. Binding="{Binding Path=CompanyName}" and Binding="{Binding Path=ContactName}" tell the grid columns which data columns (actually, which properties) to get from the table data stored in the custs object. The custs object is a Model, as in Model-View-ViewModel, and it's built as an IdeaBlade LINQ query - more on that later. Note that XAML is case-sensitive; "CompanyName" and "ContactName" are exactly how the two column names are spelled in the Customers table from whence these data come. "companyname" won't get you a thing.

The App.xaml file tells the project which is the startup screen - the one containing your menu, if you have one. In our case, there's only one window, so that's the startup window.

But the real work of the App.xaml file is to style all of the controls in all of the windows in your application. This one is very simple, but some contain thousands of lines of style code. You can also point to an external "Resource Dictionary", and your users can change it at execution time. That's all it takes to implement themes in WPF. 

As you can see, ScreenTitle is a visual style defined in App.xaml. Style="{StaticResource ScreenTitle}" tells the label to get its styling info (font size, color, etc.) from App.xaml. When you download the code, start by tweaking this style. It's way cool!

But the real smoke and mirrors is the Text property binding on the ComboBox in MainWindow.xaml. firstLetter is a public property of the ViewModel. Speaking of which, here's the ViewModel for this window (there's one per window): 

What's a _mgr? If you open the NorthwindIBModel.IB.Designer.cs file, you'll see a class called NorthwindIBEntities. That's the IdeaBlade EntityManager class that contains the generated table queries. The only reason that I can think of for even looking at the generated code is to retrieve the name of this class, so that you can add the _mgr object declaration to your ViewModel code. I'm sure that after you've done it a few hundred times, you'll know what the generated name will be. But until them, here's were you can find it. Note that _mgr is private because it's only used in the ViewModel code; custs is public because the XAML in the View has to be able to see it.

In C#, the difference between public properties and public fields is that properties have a getter that runs when you retrieve the value of the associated private field, and a setter that runs when you assign the associated private field a value. In WPF with MVVM, that's one of the ways that you can make things happen in your UI. When you assign firstLetter a value in your code, or set it interactively by selecting a new value from the ComboBox, the setter code fires. In this case, the setter code includes getByFirstLetter(Letter), which loads the custs collection, which is bound to the datagrid via the ItemsSource binding. Any questions? 

What's an ObservableCollection?

Okay, that's a good question. IdeaBlade is Entity-Framework on steroids. In case you've been busy, Entity-Framework is how Microsoft wants us to get our data. If you add an ADO Entity Model to your project, a wizard will ask you which table(s) you want to use, and will then write thousands of lines of code that expose the columns of your tables as public properties so that WPF can bind things to them. It also builds LINQ (Language INdependent Query) queries, which are what you use to get your data. You execute a query and bind the result to the DataContext (or ItemsSource) of your WPF controls, and you're done. If you install IdeaBlade DevForce, The IdeaBlade ADO Entity Model will generate IdeaBlade-compliant code, and you'll get a whole lot more bang for your buck. It also does a lot of the work for you - caching data, change notification, and more.

Add a new class project called IBModel to your solution, and immediately delete the Class1.cs file that it adds by default. Add a new item, an ADO Entity Model, to the class project. Following the steps in the resulting wizard, add the appropriate connection string, and then pick the Customers table from the list of Northwind tables. Name the saved code file NorthwindIBModel. Compile the project and add a reference to it to your UI project. Then, drag the app.config file from the Model project to the UI project, so that the program will know where to get the connection string to your data. (You'll also need to add references to three IdeaBlade dlls: IdeaBlade.Core, IdeaBlade.EntityModel, and IdeaBlade.Validation.) That should have taken all of 90 seconds. If it didn't, get a faster computer.

But Houston, we've got a a problem. LINQ is completely different from what you're used to. So get ready to look for working examples and copy them until this begins to make sense. The more you work with LINQ queries, the more sense they'll make. I've used an asynchronous query, but I also included an Execute() query, commented out.

I need to mention something about the code that's a little confusing. The ObservableCollection declaration and the constructor both refer to "customers". The syntax ObservableCollection<ClassName> uses the generics syntax introduced in an earlier version of the .NET framework.) But the actual query refers to _mgr.customer. What's up with that?

The answer can be found in the generated Model code. Customer is a record structure. Customers is a LINQ query that also contains a collection of Customer records; custs is an instance of the Customer LINQ query. That's why you see the use of custs.Add() to add customer records to the query result.

But what are those using statements at the top of the code? The first line permits leaving out the qualifier prefixes on objects that come from those classes, which are added as references when you add IBModel to the UI project's references. The next using is to simplify the reference to the ObservableCollection interface; and the third line references our Model, so that we don't have to prefix the Customers reference with the IBModel project name.

By declaring custs as a public property, we make it available to the View (the Window). By declaring it as an ObservableCollection, we get some additional functionality that helps in binding. All that remains is to create the custs object in the constructor, and assign a value to the public property firstLetter. That triggers the setter code, and we're off and running.

getByFirstLetter is called when we assign a value to firstLetter, whether in code (as in the constructor, above) or in the DropDownList, where we had the innocent-looking XAML Text="{Binding Path=firstLetter}". That's all it takes to run the query when the user either selects a letter from the DropDownComboBox or simply enters a letter using the keyboard.

The query

getByFirstLetter(string Letter) calls a LINQ query that loads data for the grid into the custs ObservableCollection. It first clears custs, and then constructs and executes the query. I've used an asynchronous query, which ordinarily requires a delegate as a target for the requisite callback. The lambda expression that's passed as a parameter in the example saves you the bother of writing a separate delegate function, but it does the same thing.

You could also use query.Execute(). Either one loads custs, which contains the public properties that expose the data in the columns of the Customer records. Note that both Execute and ExecuteAsync require the addition of a ForEach(custs.Add()) loop. That tells the query to take the records - er, entities from the query and add them to the resultset.

Anyway, notice that you don't have to get the data from each column and and assign it to a control. The "Path=" attribute takes care of it. The binding does the finding. (I just made that up.) That, it turns out, is the least of what binding in WPF does.

Conclusion

There's a lot more to MVVM. For example, there's commanding, the process that you use to tie keystrokes (like hotkeys, function keys and menu commands like Edit, New and Delete) to specific methods in your ViewModel. That's the subject of an upcoming article in this series. The implementation is elegant - which is what I've come to expect from WPF. You're going to like it - I guarantee it.

See 'ya.

Les