Beth Massi - Sharing the goodness that is VB : Entity Framework

New “How Do I” Videos Released on Entity Framework & WPF

Beth Massi — Wed, 26 Aug 2009 20:18:08 GMT

Yesterday we released a couple more videos onto the Visual Basic Developer Center on building WPF data-entry forms with Entity Framework:

That makes 5 videos total on working with EF in WPF applications. Others released previously:

These videos are based on articles I’ve posted here in the past. So if you like reading better that watching videos here you go:

There are also additional resources listed on the How Do I video pages themselves pointing to topics in the MSDN Library.

Enjoy!

Using the ReportViewer with ADO.NET Data Services and Entity Framework

Beth Massi — Thu, 20 Aug 2009 07:57:20 GMT

The Winforms ReportViewer in Visual Studio Pro will allow you define client reports with a variety of data sources. If you’re not familiar with creating client-side reports using the ReportViewer, take a look at these videos:

(The ReportViewer can also display server-based reports a la SQL Reporting Services and has a whole boatload of features that I’m not going to talk about here. For more information on this freely redistributable control, please read ReportViewer Controls (Visual Studio) in the MSDN library.)

ADO.NET Data Services was released with Visual Studio 2008 SP1 and is basically a framework for exposing your data models via RESTful web services. So if you are building a remote CRUD data access layer then this is a technology that will make that super-simple, especially if you just want to expose a few data entities as read-only report sources. (I’ve written a lot about how to use ADO.NET Data Services in a variety of ways so check out these posts if you’re interested.) Entity Framework was released at the same time and you can use EF as the data model behind your ADO.NET Data Service and expose it easily. If you’ve never created one before, check out this quick start here.

What’s the Problem?

If you’ve ever tried to use the ReportViewer to design a client-side report with an ADO.NET Data Service data source (or use an Entity Data Model directly) you may be disappointed. If you try to design a new report, the wizard may crash Visual Studio when selecting an entity. Yikes!

Let me show you what I mean, but don’t try this at home. I have an ADO.NET Data Service based on the Northwind database like the one I created here and in the quick start. I then added a Windows Forms client project to the same solution (File –> Add –> New Project, then select Windows Forms App). Now open Form1 in the client and from the toolbox under the Reporting tab, drop the Microsoft ReportViewer control onto the form and from the smart tag select “Design a New Report”.

This will open the Report Wizard. The first thing I need to do is tell it what data source to use, so I’ll select Service and click Next. This will open the Add Service Reference dialog box where I can add the reference to my data service and Visual Studio will generate the proxy objects for me. In this example my service is in the same solution as the client so I can just click the Discover button and Visual Studio will see it. I named it NorthwindService. Click OK then click Finish.

At this point I’m brought back to the Report Wizard:

Hmmmm…. I’m a little lost at this point because -- didn’t I just select the data source? Why don’t I see it?

Maybe I should have added the service reference first from the Solution Explorer instead of through the Report Wizard? You can do that and you’ll get to the same screen at this point.

So okay, I’ll click the Add Data Source button that’s calling to me. Granted, I like clicking buttons that have the ellipsis (…) on them because I’m always curious to see what’s under them, but this seems redundant.

This opens the same dialog as before but this time I’ll choose Object instead of Service. I’m choosing object this time because I’m going to try and bind to the client proxy types that were generated for me when I added the service reference. After selecting Object, click Next and expand the service namespace.

For this report I want to just display a list of Customers in the system so I’ll select Customers and then click Next.

Then… then…… are you ready?… you better sit down for this…. click Finish……. wait for it…. wait for it….. not responding…. uh ohhhh…..

Visual Studio has encountered a problem and needs to close. Darn!

Now that was fun.

How Do I Fix this?

Unfortunately the Report Wizard in Visual Studio 2008 doesn’t know how to work with many-to-many relationships and that’s exactly what we have defined in our EF Entity Data Model which is what is backing our ADO.NET Data Service. Customers have many CustomerDemographics and vice versa in Northwind. You can actually define a couple classes yourself manually and create a many-to-many association between them:

Public Class Class1

    Private _class2 As List(Of Class2)
    Public ReadOnly Property Class2() As List(Of Class2)
        Get
            Return _class2
        End Get
    End Property

End Class

Public Class Class2

    Private _class1 As List(Of Class1)
    Public ReadOnly Property Class1() As List(Of Class1)
        Get
            Return _class1
        End Get
    End Property

End Class

Try to use either class above as the data source of the report and it will crash too. Woah! So when the report designer tries to read these associations I’m guessing it gets into an infinite loop walking the association references back and forth and then it crashes. So it’s not an error with the generated proxy objects per se, the root cause is our object model. If I would have chosen Categories instead, it would have worked.

So what do we do? We could create another layer of classes without the associations on both sides if we wanted and then use those types instead but then we’d have to write code that IMO is pretty useless, just to shape the data again how we want on the client.

My recommendation is to create a separate data model for your reports that doesn’t have many-to-many associations at all. You’re going to end up with a lot of different looking entities anyways for your reports because they will most likely pull from multiple database Views and/or stored procedures. You’ll always be displaying one side of the many-to-many relationship on paper anyways.

Creating a Reporting Data Model

So let’s go back to the data service project and add a new Entity Data Model to the web project called NorthwindReport. This time I’ll just select the Customers, Orders and Order Details and all the Views defined in the database.

Next I’ll add the ADO.NET Data Service and call it NorthwindReport and configure it so that we’re only allowing read-only access to our data by setting the entity access rule like so:

Imports System.Data.Services
Imports System.Linq
Imports System.ServiceModel.Web

Public Class NorthwindReport
    Inherits DataService(Of NorthwindReportEntities)

    Public Shared Sub InitializeService(ByVal config As IDataServiceConfiguration)
        config.SetEntitySetAccessRule("*", EntitySetRights.AllRead)
    End Sub
End Class

Now back on the client we can add the service reference to this service instead. After we add the service reference we can run the Report Wizard again by selecting “Design a New Report” smart tag on the ReportViewer control like I showed in the beginning. Select Object as the data source (or Service if you didn’t add the service reference first, then you’ll have to click “Add Data Sources…” again and then select Object) and you should see the list of entities exposed in the NorthwindReport data model. Now when we select Customer, we don’t have a problem.

Design the report how you like (see the documentation for more details) by clicking through the wizard and then go back to the smart tag on the ReportViewer and you should see the report you just created in the dropdown. Next go to the code-behind for the form and in the Load handler we just set the BindingSource.DataSource property to the results of the ADO.NET Data Service LINQ query:

Imports NorthwindClient.NorthwindReportService

Public Class Form1

    Private Sub Form1_Load() Handles MyBase.Load
        'TODO: put in My.Settings
        Dim uri As New Uri("http://localhost:1933/NorthwindReport.svc/")
        'Create the service reference
        Dim db As New NorthwindReportEntities(uri)

        'Set the report's DataSource to the results of the query
        Me.BindingSource.DataSource = From c In db.Customers _
                                      Where c.Country = "USA" _
                                      Order By c.CompanyName

        Me.ReportViewer1.RefreshReport()
    End Sub
End Class

Now hit F5 to run this baby and you’ll see the report pull the data from the service and display in the form:

Recap & Resources

ADO.NET Data Services are a great way to quickly and easily expose data on the web, especially if it’s just read-only data used for remote reporting clients. The key to using the ReportViewer with ADO.NET Data Services (or an Entity Data Model directly, or even your own object model) is to make sure there are no many-to-many associations on the entities. Here are the resources you need to get started with ReportViewer and ADO.NET Data Services:

Enjoy!

Auto Access to non-Indexed Collections : Or How I Learned to Stop Worrying and Love the VB Compiler

Beth Massi — Sat, 15 Aug 2009 02:26:35 GMT

I just finished a couple more How Do I videos on using EF with WPF using VS2008 SP1 (they’ll be published soon) and while I was translating my VB code to C# I stumbled upon an error in C# that does not happen in VB. This of course got me curious and so I thought I’d share what I found out.

I have an EDM defined with a parent entity Order and child OrderDetails that I created with the designer – very basic – like I show in this video. In the example I was working on, I was putting the results of an order query into a generic list but also including the OrderDetails so I end up with an EntityCollection called OrderDetails on every Order.

OMSEntities db = new OMSEntities();

var results = from o in db.Orders.Include("OrderDetails")
              select o;

List<Order> orderList = new List<Order>(results);

However if I want to get the first Order’s first OrderDetail, I get an error in C#: “Cannot apply indexing with [] to an expression of type 'System.Data.Objects.DataClasses.EntityCollection<EFTestDAL.OrderDetail>'” when I write this line:

//ERROR
Console.WriteLine(orderList[0].OrderDetails[0].OrderDetailID);

However, the VB code works perfectly.

Dim db As New OMSEntities

Dim results = From o In db.Orders.Include("OrderDetails") _
              Select o

Dim orderList As New List(Of Order)(results)

'No Error
Console.WriteLine(orderList(0).OrderDetails(0).OrderDetailID)

So what gives in C#? At first I thought it was something with the way the EntityCollection was being generated in each of the designer code-behind for the languages, maybe I found a bug? So I created a single solution and used C# as the data access layer project and then added a C# client and a VB client project and still the same issue. VB worked fine against the C# defined EntityCollection. Hmmmm……

Next Stop, BING. I searched for the error message and no luck. Okay well it helps to actually read these error messages so let’s put on my glasses and break out my Microsoft Compiler Error Message Magic Translator* and yeah, as the title of this post suggests, the EntityCollection doesn’t actually implement an indexer. Okay so again, why does it work in VB?

The VB Compiler loves to help. It’s like uber-helpful (sometimes to its own fault, I admit), but this time it’s really helping in a good way. The way to get this to work in C# is to call the ElementAt or ElementAtOrDefault extension methods. So in C# to get the OrderDetail by index you write:

//No ERROR
Console.WriteLine(orderList[0].OrderDetails.ElementAt(0).OrderDetailID);

So what Visual Basic is doing for you is exactly that. Actually it’s calling ElementAtOrDefault for you if the collection does not implement an indexer of its own. So you can write the same syntax for all collections. This help topic on the Extension Indexer Property gave us the clue we needed. So, if an IEnumerable or IQueryable doesn't define an indexer property, VB will translate the indexer syntax to the ElementAtOrDefault operator. Good to know!

So I asked Diego on the EF team why the EntityCollection doesn’t implement an indexer. I was told that the EF team decided long time ago that since there was conceptually no guarantee on the ordering of EntityCollections, they didn’t want to give the illusion that such ordering existed by exposing an indexer. The internal implementation of EntityCollection(Of T) uses HashSet(Of T), which is super-fast and doesn’t have an indexer.

Enjoy!

*No there is no such thing as a Microsoft Compiler Error Message Magic Translator that I know of so please don’t ask! But please feel free to create one on CodePlex. ;-)

N-Tier Application Patterns with Entity Framework

Beth Massi — Thu, 06 Aug 2009 01:20:52 GMT

This month’s MSDN Magazine has a particularly good article in there by Danny Simmons, Development Manager on the Entity Framework team, on N-Tier Application Patterns with Entity Framework that I recommend reading through. He explains the design considerations you need to take into account when building n-tier applications and also discusses some of the improvements that are coming in .NET Framework 4.0 that will make building n-tier applications with EF much much easier. I’m personally looking forward to self-tracking entities myself, hooray!

Tim Mallalieu also has a good best practices article in this issue that I just started digging into regarding the next version of Entity Framework.

Enjoy!

Filtering Entity Framework Collections in Master-Detail Forms

Beth Massi — Fri, 17 Jul 2009 03:18:17 GMT

Last post I talked about how to get WPF data binding to work with master-detail entity collections. I had a couple readers ask me how they could filter the child collection instead of bringing them all down so in this post I’d like to show how you could do that. It’s actually pretty easy.

Customer (Master) –< Orders (Detail)

I created a very simple Entity Data Model (EDM) that demonstrates a Master-Detail relationship. The Orders table is defined in the database with a non-nullable foreign key CustomerID, meaning that no Order can exist without a Customer. This relationship is inferred by Entity Framework (EF) to set up the navigation properties giving us an Orders EntityCollection on Customer.

To recap, I’ve created my own ObservableCollection(of Customer) called CustomerCollection so that when the UI modifies the collection through AddItem/RemoveItem, we can instruct the ObjectContext to track these changes so that it will insert and delete entities to the database when we call SaveChanges.

The constructor takes an IEnumerable(Of Customer) which allows us to pass a LINQ to Entities query into our CustomerCollection. This executes the query against the database when we call the base class’s constructor which iterates over the query results and adds the Customer entities to our collection.

Take a look at the first chunk of code in the last post for the full code listing for the CustomerCollection class. I don’t have to make any changes to it to support filtering the children.

Loading All Detail Entities

If you want to bring down all the Orders for the selected Customer you can use the .Include extension like I’ve shown before using explicit loading.

'EF ObjectContext connects to database and tracks changes
Dim db As New OMSEntities
'inherits from ObservableCollection(Of Customer)
Dim CustomerData As CustomerCollection

'Include all Orders for Customer #1
Dim customers = From c In db.Customers.Include("Orders") _
                Where c.CustomerID = 1

CustomerData = New CustomerCollection(customers, db)

This ends up shooting one query to SQL Server to return all the Orders for the selected Customer when we pass the query into our collection. But what if we also wanted to filter the Orders? There’s a couple ways we can do this because of a cool feature of the Entity Framework.

Filtering Detail Entities with a Sub-Query

When the entities are being created in memory on the client from the query (materialized), the object state manager will attempt to hook up the entity references and collections automatically. This means that all we have to do is specify a filtered query and make sure we execute it by enumerating over the results (or calling ToList).

So say we wanted to only grab the most recent Orders where the order was placed on or after January 1st, 2009:

Dim query = From c In db.Customers _
            Where c.CustomerID = 1 _
            Select Customer = c, _
                   Orders = From o In c.Orders _
                            Where o.OrderDate >= #1/1/2009#

Dim customers = From item In query.ToList Select item.Customer

CustomerData = New CustomerCollection(customers, db)

Here I’m specifying a sub-query to only pull the Orders I want on the selected Customer. The first query creates a collection of anonymous types that have a Customer object and a filtered Orders collection. In the following query, I need to call query.ToList in order to execute the query against the database and materialize the objects. This sends one statement to SQL Server like before, but this time it’s filtered on Orders as well.

At this point the Customers and Orders are in memory and the object state manager has hooked them up for us. Meaning that the Customer now has an Orders collection like we want. As long as we Select the entire Customer and Order types in our queries this will work (as opposed to just selecting specific fields – the entity types have to match up for it to work). The second query is just a LINQ to Objects query (in memory) that we’re using so that we can pass an IEnumerable(Of Customer) to our ObservableCollection.

Filtering Detail Entities with Separate Queries

There are other ways we could write this. We could write the queries separately:

Dim customers = (From c In db.Customers _
                 Where c.CustomerID = 1).ToList()

Dim orders = (From o In db.Orders _
              Where o.Customer.CustomerID = 1 AndAlso _
                    o.OrderDate > #1/1/2009#).ToList()

CustomerData = New CustomerCollection(customers, db)

Notice that I’m calling ToList to force the queries to execute so that the objects will materialize (come into memory), then I’m just passing the Customers to the constructor because at this point the object state manager has hooked up our entities (Customer has an EntityCollection of Orders based on the filtered query). The results on the client are the same but the major difference here is that two statements are sent to SQL Server, so keep that in mind. I like the first approach better with a sub-query because of the single SQL statement that’s generated as well as the clearer looking LINQ query.

I’ve updated this sample application that also shows a variety of other data binding techniques with EF and WPF so have a look. The filter example above is in the SimpleMasterDetailBinding form.

Enjoy!

Master-Detail Data Binding in WPF with Entity Framework

Beth Massi — Wed, 15 Jul 2009 02:24:00 GMT

Today I thought I would talk about a really common scenario in data applications, creating a master-details (one-to-many) data entry form. I’ve written about WPF data binding and Entity Framework a lot in the past:

Posts:

Videos:

Today I want to pull these concepts together and walk through one way to create a master-detail form in WPF using entities from the Entity Framework. Specifically, we’ll declare CollectionViewSources in our XAML like I showed here, to bind to an ObservableCollection of entities like I showed here, where the children are explicitly loaded like I showed here. Everybody got that? ;-)

Creating the Entity Data Model

First let’s create a simple Entity Data Model (EDM) that demonstrates a Master-Detail relationship. I’ll use a simple database called OMS that has Customer and Orders tables with a non-nullable foreign key set up between them on CustomerID, meaning that no Order can exist without a Customer. This relationship is inferred by Entity Framework (EF) to set up the navigation properties. Notice that there is an Orders EntityCollection on Customer.

What we want to do is build a simple form that will let us Edit, Add, and Delete Customers and their Orders. First let’s set up the WPF Data Binding in XAML.

Defining the CollectionViewSource and Data Bindings

To recap, a CollectionViewSource is a proxy for the CollectionView which manages the currency (the position) in the list of entities. It has a property called Source which can be set in our code behind. This way, we can set up CollectionVieSources in XAML for all our data lists and bind them to the corresponding controls all in XAML. Then at runtime in our code we set the Source properties and only at that time does the data pull from the database.

To define a Master-Detail relationship we define two CollectionViewSources one for the master and one for the detail collections. Then on the detail we set the Source property to the master CollectionViewSource and then specify the Path property as the name of the child collection. In our case the name of the collection on Customer is “Orders”. So we can specify the XAML like so:

<Window.Resources>
    <CollectionViewSource x:Key="MasterViewSource" />
    <CollectionViewSource x:Key="DetailsViewSource" 
                    Source="{Binding Source={StaticResource MasterViewSource}, Path='Orders'}" />
</Window.Resources>

Now as the position changes in the MasterViewSource to point to a new Customer, the DetailsViewSource will filter automatically to only those related Orders for that Customer. We can now set the rest of the data bindings on the controls on the form by setting the BindingContext of the container controls to the CollectionViewSource we want to display. For example, we can set up a StackPanel to contain the Customer fields and set the StackPanel.DataContext to the MasterViewSource. Under that we can set up a ListView to display the Orders by setting the ListView.ItemsSource to the DetailsViewSource.

<Grid>
...
    <StackPanel Name="StackPanel2" 
                Grid.Column="1" 
                DataContext="{Binding Source={StaticResource MasterViewSource}}">
        <TextBox Name="TextBox1" IsReadOnly="True" 
                 Text="{Binding Path=CustomerID, Mode=OneWay}"/>
        <TextBox Name="TextBox5"
                 Text="{Binding Path=LastName}"/>
...
    </StackPanel>
...
    <ListView Grid.Row="3" Name="ListView1" 
              IsSynchronizedWithCurrentItem="True"
              ItemsSource="{Binding Source={StaticResource DetailsViewSource}}">
        <ListView.View>
            <GridView>
                <GridViewColumn Header="ID" Width="75">
                    <GridViewColumn.CellTemplate>
                        <DataTemplate>
                        <Label Content="{Binding Path=OrderID}" 
                                     Margin="-6,0,-6,0"/>
                        </DataTemplate>
                    </GridViewColumn.CellTemplate>
                </GridViewColumn>
                <GridViewColumn Header="Order Date" Width="100">
                    <GridViewColumn.CellTemplate>
                        <DataTemplate>
                            <TextBox Text="{Binding Path=OrderDate}" 
                                     Margin="-6,0,-6,0"/>
                        </DataTemplate>
                    </GridViewColumn.CellTemplate>
                </GridViewColumn>
...

The only thing we need to do now is set the Source property of the MasterViewSource in code to the collection of our Customer entities.

Defining the Master-Detail Entities in an ObservableCollection

I showed before how we can create a collection of entities that inherits from ObservableCollection in this post to make it easier to work with WPF data binding. But in that example we were only working with a simple collection of Customers and not their Orders. If you recall, the ObjectContext is what tracks changes on entities so in order for the ObjectContext to be notified that adds and deletes to the ObservableCollection need to be tracked you need to override the InsertItem and RemoveItem methods so that you can tell the ObjectContext to either add or delete the entity which will ultimately execute against the database. In the constructor I pass a reference to the ObjectContext. You can also pass in any collection of entities, say from a LINQ query, and then add them to the ObservableCollection. However, we need to make a couple modifications to our collection so that we can also track the child order entities correctly.

Adds to the Customer.Orders EntityCollection will will cause the addition of a new Order to the collection as well as the association to Customer automatically. However removing the Order from the Customer.Orders EntityCollection will only remove the association and will not attempt to actually delete the Order from the database. Instead it attempts to set the CustomerID to NULL (to remove the association from the Customer) but since we have referential integrity set up to disallow this we will get an error if we attempt to SaveChanges.

In a lot of scenarios it makes sense to just remove the association and set the foreign key to NULL in the database. But in this example we really mean to delete the Order record completely when the Order is removed from the collection. So the key is adding an event handler to the AssociationChanged event on the Orders EntityCollection that’s hanging off our Customer entity and telling the ObjectContext to explicitly delete the Order.

Public Class CustomerCollection
    Inherits ObservableCollection(Of Customer)

    Private _context As OMSEntities
    Public ReadOnly Property Context() As OMSEntities
        Get
            Return _context
        End Get
    End Property


    Sub New(ByVal customers As IEnumerable(Of Customer), ByVal context As OMSEntities)
        MyBase.New(customers)
        _context = context

        For Each c In customers
            AddHandler c.Orders.AssociationChanged, AddressOf Orders_CollectionChanged
        Next
    End Sub

    Protected Overrides Sub InsertItem(ByVal index As Integer, ByVal item As Customer)
        AddHandler item.Orders.AssociationChanged, AddressOf Orders_CollectionChanged

        'Tell the ObjectContext to start tracking this customer entity
        Me.Context.AddToCustomers(item)
        MyBase.InsertItem(index, item)
    End Sub

    Protected Overrides Sub RemoveItem(ByVal index As Integer)
        Dim customer = Me(index)
        RemoveHandler customer.Orders.AssociationChanged, AddressOf Orders_CollectionChanged

        For i = customer.Orders.Count - 1 To 0 Step -1
            'When deleting a customer, delete any orders if any exist
            Me.Context.DeleteObject(customer.Orders(i))
        Next

        'Tell the ObjectContext to delete this customer entity
        Me.Context.DeleteObject(customer)
        MyBase.RemoveItem(index)
    End Sub

    Private Sub Orders_CollectionChanged(ByVal sender As Object, _
                                         ByVal e As CollectionChangeEventArgs)
        If e.Action = CollectionChangeAction.Remove Then
            'Adding an order to a customer is handled automatically 
            ' for us but we need to tell the ObjectContext to delete the order
            ' if an order is removed from the Orders EntityCollection 
            Me.Context.DeleteObject(CType(e.Element, Order))
        End If
    End Sub
End Class

Loading the Master-Detail Entities

Finally we’re ready to write a LINQ query to load the entities into our CustomerCollection and then set that as the Source property of the MasterViewSource. In this example I’m loading the Orders explicitly by calling .Include(“Orders”) on the LINQ query which constructs a single statement to retrieve the Customer and all their Orders from the database. I discuss explicit load in this post.

We can then grab a reference to the MasterViewSource & DetailViewSource’s View property in order to add/remove items in the collections. When we’re done, we can call SaveChanges on the ObjectContext and the database will be updated.

Private db As New OMSEntities 'EF ObjectContext connects to database and tracks changes
Private CustomerData As CustomerCollection 'inherits from ObservableCollection

Private MasterViewSource As CollectionViewSource
Private DetailViewSource As CollectionViewSource

'provides currency to controls (position & movement in the collections)
Private WithEvents MasterView As ListCollectionView
Private DetailsView As BindingListCollectionView

Private Sub Window_Loaded() Handles MyBase.Loaded

    Dim query = From c In db.Customers.Include("Orders") _
                Where c.CustomerID = 1 _
                Select c

    Me.CustomerData = New CustomerCollection(query, db)

    Me.MasterViewSource = CType(Me.FindResource("MasterViewSource"), CollectionViewSource)
    Me.DetailViewSource = CType(Me.FindResource("DetailsViewSource"), CollectionViewSource)
    Me.MasterViewSource.Source = Me.CustomerData

    Me.MasterView = CType(Me.MasterViewSource.View, ListCollectionView)
    Me.DetailsView = CType(Me.DetailViewSource.View, BindingListCollectionView)
End Sub

Private Sub MasterView_CurrentChanged() Handles MasterView.CurrentChanged
    'We need to grab the new child view when the master's position changes
    Me.DetailsView = CType(Me.DetailViewSource.View, BindingListCollectionView)
End Sub

Private Sub btnSave_Click() Handles btnSave.Click
    Try
        db.SaveChanges()
        MessageBox.Show("Customer data saved.", Me.Title, MessageBoxButton.OK, MessageBoxImage.Information)
    Catch ex As Exception
        MsgBox(ex.ToString())
    End Try
End Sub

Private Sub btnDelete_Click() Handles btnDelete.Click
    If Me.MasterView.CurrentPosition > -1 Then
        Me.MasterView.RemoveAt(Me.MasterView.CurrentPosition)
    End If
End Sub

Private Sub btnAdd_Click() Handles btnAdd.Click
    Dim customer = CType(Me.MasterView.AddNew, Customer)
    Me.MasterView.CommitNew()
End Sub

Private Sub btnPrevious_Click() Handles btnPrevious.Click
    If Me.MasterView.CurrentPosition > 0 Then
        Me.MasterView.MoveCurrentToPrevious()
    End If
End Sub

Private Sub btnNext_Click() Handles btnNext.Click
    If Me.MasterView.CurrentPosition < Me.MasterView.Count - 1 Then
        Me.MasterView.MoveCurrentToNext()
    End If
End Sub

Private Sub btnAddDetail_Click() Handles btnAddDetail.Click
    Dim order = CType(Me.DetailsView.AddNew, Order)
    Me.DetailsView.CommitNew()
End Sub

Private Sub btnDeleteDetail_Click() Handles btnDeleteDetail.Click
    If Me.DetailsView.CurrentPosition > -1 Then
        Me.DetailsView.RemoveAt(Me.DetailsView.CurrentPosition)
    End If
End Sub

Now we can Add, Edit, and Delete Customer and their Orders at the same time and changes will be propagated properly to the database through Entity Framework in one call to SaveChanges. I’ve updated this complete sample application that demonstrates this as well as other aspects of WPF Data Binding with Entity Framework so have a look.

UPDATE: Milind talks about some of the tooling improvements in Visual Studio 2010 on the VSData blog regarding building WPF forms against Entity Data Models so check it out --> WPF Data Binding: Creating a Master-Details form in Visual Studio 2010

Enjoy!

Implementing Validation in WPF on Entity Framework Entities

Beth Massi — Wed, 08 Jul 2009 03:14:00 GMT

I’ve blogged before about implementing validation on LINQ to SQL classes as well as how to customize the display of error messages in WPF. In this post I want to show how you can use these same techniques to validate entities coming from the Entity Framework (EF). Like LINQ to SQL classes, Entity Framework entities are implemented as partial classes so that you can extend them with your own code on top of the code that the designers generate for you. You can extend EF entities in a similar way as LINQ to SQL classes.

Creating the Partial Class

Let’s take the example that I started here in this How Do I video on building a simple data entry form to edit customers. You can download the code for that video here. In this sample I have two projects, one for the WPF client (WpfEfDataEntry) and one for the Data Access Layer (WpfEfDAL) that contains a simple Entity Data Model (edmx) of a little database I created that tracks customers and their orders.

To extend the Customer class that is generated from the EF designer, right-click on the DAL project and select Add –> Class then name it Customer. This places the class in the same Namespace as the entities that are generated by the designer. This is necessary for partial classes to work. (Partial classes are just a way that you can define one class in multiple physical files and Visual Studio will handle compiling them into one class for you.)

Here’s a trick in VB. You know you got your partial class in the right namespace when you drop down the Declarations dropdown and you see the list of partial methods and properties that the class defines.

Also in VB the Partial keyword is only required on one of the class declarations in one of the files. (In C# it’s required on all of them.) The EF designer generates the Customer class with the partial keyword. If you click the “Show all Files” button on the Solution Explorer toolbar and then expand the .edmx you can open the .Designer file and see the entity Partial Class definitions:

Partial Public Class Customer

You can of course be explicit in VB and add the Partial keyword to all your partial class files as well.

Adding Validation to the Partial Class

To add validation we can implement the IDataErrorInfo interface in our customer partial class. Using this interface will make validation errors display in Winforms as well as WPF so I tend to prefer this implementation over others like ValidationRules collection in WPF. For this example let’s make sure that the LastName field isn’t empty but we’ll also provide a default value by specifying it in the constructor. This code is the same code we would use if we were working with LINQ to SQL classes.

Imports System.ComponentModel

Partial Public Class Customer
    Implements IDataErrorInfo

#Region "IDataErrorInfo Members"
    Private m_validationErrors As New Dictionary(Of String, String)

    Private Sub AddError(ByVal columnName As String, ByVal msg As String)
        If Not m_validationErrors.ContainsKey(columnName) Then
            m_validationErrors.Add(columnName, msg)
        End If
    End Sub

    Private Sub RemoveError(ByVal columnName As String)
        If m_validationErrors.ContainsKey(columnName) Then
            m_validationErrors.Remove(columnName)
        End If
    End Sub

    Public ReadOnly Property HasErrors() As Boolean
        Get
            Return m_validationErrors.Count > 0
        End Get
    End Property

    Public ReadOnly Property [Error]() As String _
        Implements System.ComponentModel.IDataErrorInfo.Error
        Get
            If m_validationErrors.Count > 0 Then
                Return "Customer data is invalid"
            Else
                Return Nothing
            End If
        End Get
    End Property

    Default Public ReadOnly Property Item(ByVal columnName As String) As String _
        Implements System.ComponentModel.IDataErrorInfo.Item
        Get
            If m_validationErrors.ContainsKey(columnName) Then
                Return m_validationErrors(columnName).ToString
            Else
                Return Nothing
            End If
        End Get
    End Property
#End Region

    Public Sub New()
        'Set defaults
        Me.LastName = "[new]"
    End Sub

Now we can write our validation code to check the LastName field. If you look back at the generated Customer class in the .Designer file, notice that there are OnFieldNameChanging and OnFieldNameChanged methods that are also declared as Partial. These are partial methods, a new feature introduced with Visual Studio 2008, that allow you to supply additional code that is called from the generated class. The Changing/Changed methods are called in the property setters. We’ll define the OnLastNameChanged to make sure the user enters a LastName:

    ''' <summary>
    ''' This method is called in the LastName property setter of the customer
    '''  partial class generated by the Entity Data Model designer.
    ''' </summary>
    Private Sub OnLastNameChanged()
        'Perform validation. 
        If _LastName Is Nothing OrElse _LastName.Trim() = "" OrElse _LastName.Trim() = "[new]" Then
            Me.AddError("LastName", "Please enter a last name.")
        Else
            Me.RemoveError("LastName")
        End If
    End Sub

End Class

Now all we need to do is specify on the binding in the XAML of the WPF form to display the validation errors.

<TextBox Name="txtLastName" Width="Auto" Height="28" Margin="3" 
         Text="{Binding Path=LastName, ValidatesOnDataErrors=True}"/>

This is exactly the same as we did in this post when working with LINQ to SQL. Read that post to also see how to change the default error template which controls how the errors are displayed.

Adding Validation to Entity References

As you can see validating scalar properties on EF entities works the same as with LINQ to SQL classes. However what if we wanted to make sure that an entity reference was also specified on an EF entity? I’ve posted before about how to get notified when entity references change. But what if we also want to make sure an entity reference is not empty? For instance, in the case of the Order entity above, how would we write a validation to make sure that the Customer entity reference was specified on the Order before we tried to save?

Looking back up at the Customer (1)—(*) Order in the diagram above, the Order entity has a reference to its Customer parent as specified by the navigation property. In the database there is a foreign key relationship on CustomerID and that is inferred here by EF. This is a difference from LINQ to SQL classes where the classes contain the foreign keys as scalar properties as well. We can’t validate EF entities the same way because there are no scalar properties for the foreign keys. Instead we need to add an event handler to the AssociationChanged event on the entity reference (like I showed before) and then add in our validation. Remember that the AssociationChanged event will fire twice when we are selecting a new reference, once when the old entity reference is removed and then once when the new one is added.

Imports System.ComponentModel

Public Class Order
    Implements IDataErrorInfo

    Public Sub New()
        'Handle this event so that UI can be notified if the customer is changed
        AddHandler Me.CustomerReference.AssociationChanged, AddressOf Customer_AssociationChanged

        'Set defaults
        Me.OrderDate = Date.Today()
        'Customer is required 
        Me.AddError("Customer", "Please select a customer.")
    End Sub

    Private Sub Customer_AssociationChanged(ByVal sender As Object, _
                                            ByVal e As CollectionChangeEventArgs)
        If e.Action = CollectionChangeAction.Remove Then
            OnPropertyChanging("Customer")
        Else
            If e.Action = CollectionChangeAction.Add Then
                Me.RemoveError("Customer")
            End If
            OnPropertyChanged("Customer")
        End If
    End Sub

What I’m doing is putting the Order in an immediate error state so that the user can see that a Customer must be selected on the Order before it is valid. The error will only go away once they select a Customer.

I’ve created a sample application that you can download from Code Gallery that demonstrates using EF with WPF in a variety of ways including this example so have a look. Also make sure you check out these How Do I videos on EF and WPF.

Enjoy!

New “How Do I” Video Series Released

Beth Massi — Thu, 02 Jul 2009 03:28:50 GMT

I just released 3 new videos onto the VB Dev Center starting a new series on how to do WPF data binding with Entity Framework using Visual Studio 2008 Service Pack 1. This is a “no frills” WPF series that focuses on data so you won’t see any other tools used besides Visual Studio 2008 SP1 and no flashy animations.

#1 | How Do I: Get Started with Entity Framework in WPF Applications?

#2 | How Do I: Build a WPF Data Entry Form Using Entity Framework?

#3 | How Do I: Create a WPF Lookup Combobox using Entity Framework?

The videos are a bit longer than your normal 5-minute “How Do I” videos but I tried to keep them short by re-using the data access layer I build in the first one. I hope this doesn’t confuse people. Believe me when I say this will get a lot better, especially tooling-wise, in Visual Studio 2010. But this is a good introduction to building WPF data apps against Entity Framework with the version of Visual Studio that is available now! :-)

Enjoy!

WPF Data Binding Samples on Code Gallery

Beth Massi — Wed, 17 Jun 2009 22:41:28 GMT

One of the many samples released for Visual Studio 2010 Beta 1 that you should be aware of are examples of WPF data binding against Entity Data Models. You can find some easy to follow samples here: http://code.msdn.microsoft.com/WPFDatabinding

This sample demonstrates how to create a WPF Forms solution that checks user input with validation code, demonstrates common controls such as DataGrid and ComboBox, and shows typical data manipulation including create, read, update, and delete. The sample solution is available in both Visual Basic and C# and is intended for use with Visual Studio 2010 Beta 1 and with the .NET Framework 3.5. In the future, we will release a sample that performs with the .Net Framework 4.0 Beta.

Check out the VS Data Team blog for more information on WPF data-binding and Karl’s blog on a great WPF sample series.

Enjoy!

Using the WPF ObservableCollection with EF Entities

Beth Massi — Sat, 09 May 2009 01:29:00 GMT

The ObservableCollection is a special WPF collection that provides proper notifications to the UI when items are added, removed, or the list is refreshed because it implements INotifyCollectionChanged. It’s common to use this collection (or inherit from it) to contain your business objects you want to bind to in WPF.

Class Window1
    Private CustomerData As ObservableCollection(Of Customer)

You can then set up a CollectionViewSource and use it’s View property to get a reference to the ListCollectionView in order to add and remove items instead of working with the source collection directly. This decouples your data source (and therefore any collection logic) from the form itself making it much easier to change sources later. I’ve showed how to use CollectionViewSources before but basically you just declare them in the Window.Resources section and bind to them in XAML:

<Window x:Class="Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="282" Width="440" Name="Window1">
    <Window.Resources>
        <CollectionViewSource x:Key="CustomerSource" />
    </Window.Resources>
    <Grid DataContext="{Binding Source={StaticResource CustomerSource}}">

And then you can set the Source property in code to your collection and obtain the ListCollectionView.

Dim customerSource = CType(Me.Resources("CustomerSource"), CollectionViewSource)
customerSource.Source = Me.CustomerData

Me.View = CType(customerSource.View, ListCollectionView)

Then you use the View to add and remove items from the collection and the UI will update properly:

Private Sub btnDelete_Click() Handles btnDelete.Click
       If Me.View.CurrentPosition > -1 Then
           'removes the currently selected customer from the underlying collection 
           Me.View.RemoveAt(Me.View.CurrentPosition)
       End If
   End Sub

   Private Sub btnAdd_Click() Handles btnAdd.Click
       'adds a new customer to the underlying collection 
       Dim customer = CType(Me.View.AddNew, Customer)
       'do something with customer if needed...
       Me.View.CommitNew()
   End Sub

Calling these methods on the ListCollectionView will execute the InsertItem and RemoveItem methods on the ObservableCollection.

Now if you are using an Entity Data Model (EDM) the designer in Visual Studio 2008 SP1 will generate entity classes for you that you can also bind to in your UI. Access to these entities is done through the ObjectContext and the designer also creates a class for you that inherits from this when you create the EDM. It is named something like xxxEntites. (For instance, in Visual Studio 2008 SP1 “Add New Item” and select ADO.NET Entity Data Model and name it Northwind.edmx. Generate from Database and select Northwind. Select all the tables and then the designer will generate an ObjectContext called NorthwindEntities and entity classes based on the tables in the database.)

Because the ObjectContext is what tracks changes on entities you can place entities inside an ObservableCollection but in order for the ObjectContext to be notified that adds and deletes need to be tracked you need to write a bit of code. The easiest thing to do is to create your own class that inherits from ObservableCollection and override the InsertItem and RemoveItem methods so that you can tell the ObjectContext to either add or delete the entity which will ultimately execute against the database. In the constructor pass a reference to the ObjectContext. You can also pass in any collection of entities, say from a LINQ query, and then add them to the ObservableCollection. For example:

Imports NorthwindDAL
Imports System.Collections.ObjectModel

Public Class CustomerCollection
    Inherits ObservableCollection(Of Customer)

    Private _context As NorthwindEntities
    Public ReadOnly Property Context() As NorthwindEntities
        Get
            Return _context
        End Get
    End Property

    Sub New(ByVal customers As IEnumerable(Of Customer), ByVal context As NorthwindEntities)
        MyBase.New(customers)
        _context = context
    End Sub

    Protected Overrides Sub InsertItem(ByVal index As Integer, ByVal item As Customer)
        Me.Context.AddToCustomers(item)
        MyBase.InsertItem(index, item)
    End Sub

    Protected Overrides Sub RemoveItem(ByVal index As Integer)
        Me.Context.DeleteObject(Me(index))
        MyBase.RemoveItem(index)
    End Sub

End Class

Then you can use the collection on your WPF form instead like so:

Imports NorthwindDAL

Class Window1
    Private db As New NorthwindEntities
    Private CustomerData As CustomerCollection
    Private View As ListCollectionView

    Private Sub Window1_Loaded() Handles MyBase.Loaded

        Dim results = From c In db.Customers _
                      Where c.City.ToLower = "seattle" _
                      Order By c.LastName, c.FirstName _
                      Select c

        Me.CustomerData = New CustomerCollection(results, db)

        Dim customerSource = CType(Me.Resources("CustomerSource"), CollectionViewSource)
        customerSource.Source = Me.CustomerData
        Me.View = CType(customerSource.View, ListCollectionView)
    End Sub

    Private Sub btnSave_Click() Handles btnSave.Click
        Try
            db.SaveChanges()
            MsgBox("Customer data was saved.")
        Catch ex As Exception
            MsgBox(ex.ToString())
        End Try
    End Sub

    Private Sub btnDelete_Click() Handles btnDelete.Click
        If Me.View.CurrentPosition > -1 Then
            Me.View.RemoveAt(Me.View.CurrentPosition)
        End If
    End Sub

    Private Sub btnAdd_Click() Handles btnAdd.Click
        Dim customer = CType(Me.View.AddNew, Customer)
        'do something with customer if needed...
        Me.View.CommitNew()
    End Sub

End Class

Now any updates, adds or deletes you make in the UI will be propagated to the database through the Entity Framework.

Enjoy!

Notifying the UI when Entity References Change in Lookup Comboboxes

Beth Massi — Tue, 05 May 2009 05:51:20 GMT

Last week I wrote about how to data bind WPF lookup comboboxes to entities returned from the Entity Framework. I described that the key to this type of binding is setting the SelectedItem to the object reference itself on the navigation property instead of setting SelectedValue and SelectedValuePath as in the case when you have foreign key scalar properties like LINQ to SQL classes or DataTables.

However, depending on your UI, you may need a notification to fire when the entity reference changes. By default this doesn’t happen with entities generated by the EF designer. Only scalar properties raise change notifications. For instance, going back to our Customer (1)—(*) Order example, the Order entity has a reference to its Customer parent as specified by the navigation property:

In the database there is a foreign key relationship on CustomerID and that is inferred here by EF. If you look at the Order class that is generated you will see only change notifications raised on the scalar properties, not the navigation properties. For instance, if we take a look at a scalar property that is generated you will see the change notification partial methods generated as well:

Partial Public Class Order
    Inherits Global.System.Data.Objects.DataClasses.EntityObject
.
.
.
    Public Property OrderID() As Integer
        Get
            Return Me._OrderID
        End Get
        Set
            Me.OnOrderIDChanging(value)
            Me.ReportPropertyChanging("OrderID")
            Me._OrderID = StructuralObject.SetValidValue(value)
            Me.ReportPropertyChanged("OrderID")
            Me.OnOrderIDChanged
        End Set
    End Property
    Private _OrderID As Integer
    
    Partial Private Sub OnOrderIDChanging(ByVal value As Integer)
    End Sub
    
    Partial Private Sub OnOrderIDChanged()
    End Sub

.
.
.

EF entities that are generated by the designer inherit from EntityObject that in turn inherits from StructuralObject that implements INotifyPropertyChanged. This interface is necessary for notifying the UI (WPF and Winforms) that data bound controls should refresh their value. So say you programmatically change a scalar property then any controls bound to that property will be refreshed with the new value automatically. Or in many cases you have a UI with multiple controls bound to the same property. If the user makes a change to one control, the rest update automatically.

However this notification isn’t generated on entity references. Which means that if you have a lookup combobox set up like I described in last week’s post and also have another control bound to the same Customer navigation property, then it won’t refresh properly.

For instance, say we have an Order form with a combobox set up like before, where the SelectedItem is bound to the Customer property (SelectedItem="{Binding Path=Customer}"), but we also have a listbox that shows OrderDate, Customer.LastName, Customer.FirstName:

<ListBox Grid.Row="1" Name="ListBox1" ItemsSource="{Binding}" IsSynchronizedWithCurrentItem="True">
<ItemsControl.ItemTemplate>
    <DataTemplate>
        <StackPanel Orientation="Horizontal">
            <TextBlock Width="60" Text="{Binding Path=OrderDate, StringFormat='d'}" />
            <TextBlock Text="{Binding Path=Customer.LastName}" />
            <TextBlock Width="5">, </TextBlock>
            <TextBlock Text="{Binding Path=Customer.FirstName}" />
        </StackPanel>
    </DataTemplate>
</ItemsControl.ItemTemplate>

If the user changes the OrderDate then that change will automatically be reflected in the listbox. But if the user changes the Customer in the dropdown combobox then it will NOT update the listbox because a change notification is not raised on Customer. What’s also interesting is if you look at that part of the generated Order entity then you will actually see two properties, one we expect called Customer and one called CustomerReference:

.
.
.
Public Property Customer() As Customer
    Get
        Return CType(Me, IEntityWithRelationships).RelationshipManager. _
        GetRelatedReference(Of Customer)("OMSModel.FK_Orders_Customer", "Customer").Value
    End Get
    Set(ByVal value As Customer)
        CType(Me, IEntityWithRelationships).RelationshipManager. _
        GetRelatedReference(Of Customer)("OMSModel.FK_Orders_Customer", "Customer").Value = value
    End Set
End Property
.
.
.
Public Property CustomerReference() As EntityReference(Of Customer)
    Get
        Return CType(Me, IEntityWithRelationships).RelationshipManager. _
        GetRelatedReference(Of Customer)("OMSModel.FK_Orders_Customer", "Customer")
    End Get
    Set(ByVal value As EntityReference(Of Customer))
        If (Not (value) Is Nothing) Then
            CType(Me, IEntityWithRelationships).RelationshipManager. _
            InitializeRelatedReference(Of Customer)("OMSModel.FK_Orders_Customer", "Customer", value)
        End If
    End Set
End Property

The Customer property is a navigation property to the parent Customer entity itself as we expect. The CustomerReference is an EntityReference class. This class describes the relationship between the Order and Customer. It also defines an event called AssociationChanged that you can handle to notify the UI properly when the reference changes. When you change the reference this event will fire twice, first to remove the old reference and then again to add the new one. You can easily extend the Order partial class by creating another Partial Class declaration for Order in the same namespace (which is automatically imported in VB) and then calling the appropriate property change notifications:

Imports System.ComponentModel

Partial Public Class Order
    Sub New()
        MyBase.New()
        AddHandler Me.CustomerReference.AssociationChanged, AddressOf Customer_AssociationChanged
    End Sub

    Private Sub Customer_AssociationChanged(ByVal sender As Object, _
                                            ByVal e As CollectionChangeEventArgs)
        If e.Action = CollectionChangeAction.Remove Then
            OnPropertyChanging("Customer")
        Else
            OnPropertyChanged("Customer")
        End If
    End Sub
End Class

So now we can change the Customer in the dropdown and the UI will be notified properly. Sweet. For more information on Entity Framework and data binding see this topic in the MSDN library.

Enjoy!

Data Binding WPF Lookup Combobox Values to EF Entities

Beth Massi — Thu, 30 Apr 2009 17:57:00 GMT

It’s extremely common to have to hook up lookup tables on your data entry forms in order to populate foreign keys in a database. I’ve talked about how to do this in Winforms and WPF with Datasets and LINQ to SQL before:

The common theme between all of these is that the data sources, either the LINQ to SQL classes or the DataTables that we bind to, uses a navigation path based on the foreign key and that foreign key is exposed as a property (or DataColumn). For instance if we have a Customer related to Orders we would have a CustomerID property on Orders.

DataSets (like databases) rely on this type of navigation. So when you want to find the parent Customer of an Order you have to know the relation. Using typed datasets helps you more but you still end up having to know the details of relationships and foreign keys of the DataSet. That’s why people who are familiar with databases are usually comfortable with working with DataSets.

LINQ to SQL classes also include navigation properties as direct object references and collections. So they have both the foreign key and the navigation properties. Customer will have a collection of Orders and Order will have a reference back to Customer but the classes also contain the CustomerID property. This isn’t “pure” I suppose but it does make data binding and subsequent saves back to the database pretty much a no brainer.

For instance say I want to hook up a lookup combobox using a LINQ to SQL class on an Order with a reference to Customer. I want to display a list of Customers the user can pick from and that Customer should be associated with that Order. It’s pretty straight forward and works the same with DataTables.

XAML:

<Window.Resources>
    <CollectionViewSource x:Key="OrdersSource" />
    <CollectionViewSource x:Key="CustomerLookup" />
</Window.Resources>

<Grid Grid.Row="1" Name="Grid1" DataContext="{Binding Source={StaticResource OrdersSource}}">
<ComboBox Height="23" Name="ComboBox1" Width="177" Margin="2"  HorizontalAlignment="Left" 
          IsEditable="False"
          ItemsSource="{Binding Source={StaticResource CustomerLookup}}"
          DisplayMemberPath="LastName"
          SelectedValuePath="CustomerID" 




          SelectedValue="{Binding Path=CustomerID}" 
          />
...

Code-behind:

Class Window1
    Private db As New MyDataObjectContext
    Private OrderData As IEnumerable(Of Order)

    Private Sub Window1_Loaded(ByVal sender As Object, ByVal e As System.Windows.RoutedEventArgs) Handles Me.Loaded
        'Load all the orders from the database
        Me.OrderData = db.Orders
        'Get the customer lookup list (this is the Combobox ItemsSource)
        Dim customerList = From c In db.Customers _
                           Where c.Orders.Count > 0 _
                           Order By c.LastName, c.FirstName

        Dim ordersSource = CType(Me.FindResource("OrdersSource"), CollectionViewSource)
        ordersSource.Source = Me.OrderData
        Dim custSource = CType(Me.FindResource("CustomerLookup"), CollectionViewSource)
        custSource.Source = customerList.ToList()

    End Sub
...

Almost all of this code is just to set up the context of this discussion, you can watch this video for details on building a complete example. Here I’m using CollectionViewSources in the XAML and setting their Source property in code. This technique is handy especially if you are using nested DataTemplates. The important piece to note are the four properties on the Combobox. ItemsSource, DisplayMemberPath, SelectedValue, and SelectedValuePath. To set up your combobox:

Set the ItemsSource to the list of Customers you want to display in the Combobox.
Next set the DisplayMemberPath to the property name on this list that you want to use to display in the list, here I used LastName.
Then set the SelectedValuePath to the property name on this list that will be used to populate the foreign key value on the Order.
Finally you set the SelectedValue to the property binding on the Order that is foreign key. LINQ to SQL (and DataSets) will happily save your data with this binding in place.

This is how you always bind DataTables and it also works well for LINQ to SQL classes. But since LINQ to SQL classes also include the navigation properties (the Orders collection on Customer and the Customer object reference on Order) you can use a different technique by binding directly to the Customer reference. This is the only choice we have with Entity Framework entities in .NET 3.5 SP1.

What’s unique with Entity Framework is that the associations between other entities use only navigation properties -- so there isn’t a CustomerID foreign key property value on the Order at all.

What you have to do instead is bind directly to the Customer object reference. The change in the above example is the Combobox binding in XAML:

<ComboBox Height="23" Name="ComboBox1" Width="177" Margin="2"  HorizontalAlignment="Left" 
          IsEditable="False"
          ItemsSource="{Binding Source={StaticResource CustomerLookup}}"
          DisplayMemberPath="LastName"          
          SelectedItem="{Binding Path=Customer}" 
          />

The important pieces in this case are the three properties on the Combobox. ItemsSource, DisplayMemberPath, and SelectedItem.

Set the ItemsSource to the list of Customers you want to display in the Combobox -- same as before.
Next set the DisplayMemberPath to the property name on this list that you want to use to display in the list, here I used LastName – same as before.
Now set the SelectedItem to the property binding on the Order that is the navigation property to Customer.

This will work properly with LINQ to SQL classes and Entity Framework entities but there is one caveat. You need to make sure that you pull the entire Customer entity into in the lookup list from the same ObjectContext you used to query the Orders. This is because the same ObjectContext (DataContext in LINQ to SQL) needs to resolve the entity references between the queries. Entity Framework does this based on the EntityKeys. The neat side effect of this with EF is that you don’t have to pull down the Customers with the Orders query, they will automatically become references when the Customer lookup list is queried through the same context. (See my post on explicit load for more details on how to bring down related EF entities when you only make one call.)

This behavior may be desired in a lot of scenarios but if we do not need to modify the Customer, like in our example, this can be overkill especially if the Customer has a lot of large fields you aren’t using. In the first example we could have only pulled a subset of fields from the Customer table – the only required ones would be the ones used in the data binding, CustomerID and LastName. So with DataTables and LINQ to SQL classes that bind on the values we could have optimized our lookup list query to:

Dim customerList = From c In db.Customers _
                   Where c.Orders.Count > 0 _
                   Order By c.LastName, c.FirstName _
                   Select c.CustomerID, c.LastName

This will not work if we bind directly to the navigation properties because the customerList is now a list of anonymous types and not a list of Customer entities. So binding to the values gives you greater flexibility with your lookup list queries. Unfortunately in the current version of EF you cannot bind this way but they are planning to enable this in the next version. In .NET 4.0 the EF team will add support for a new type of association called "FK Associations". Read more about that here.

And I’m working on the next set of WPF Forms over Data How Do I videos, this time with Entity Framework, that will hopefully explain how to use EF in practical way by building WPF data applications. Stay tuned!

Enjoy!

Programming Entity Framework Book

Beth Massi — Wed, 18 Feb 2009 05:11:16 GMT

Julie Lerman's Programming Entity Framework book just arrived today! I've been skimming around it all day and so far Chapter 8 is my favorite but I'm sure once I get to Chapter 14 that will take the cake :-)

Thanks Julie! (especially for all the great VB code!)

How Do I videos here we come.....

Enjoy!

OBA Part 1 - Exposing Line-of-Business Data

Beth Massi — Wed, 04 Feb 2009 01:23:24 GMT

Last post I talked about the high-level architecture of our Office Business Application for the new Northwind Traders. There are a lot of different architecture options to consider when building an OBA. OBA is all about using Microsoft Office with your Line of Business (LOB) data. Whether that involves using SharePoint as well depends on the application. Since we wanted to store the unstructured data (the Northwind customer P.O.) SharePoint is a good fit here.

There are a lot of options when thinking about how to expose your LOB data. For instance, you may already have a service oriented architecture at the enterprise that exposes data contracts and processes that you can consume from Office clients. Or maybe you have a small business and have decided to expose a simple service that returns and consumes n-tier DataSets directly. Or you already have a custom LOB data entry system using custom business objects and you want to reuse the business layer in the Office client. OBA doesn't dictate how you expose this data. Because you can consume data in Office clients the same way you do in Windows apps the same types of decisions need to be made.

When we sat down to write the new Northwind Traders application we thought about how our data would need to behave and what would be the best way for all the pieces to easily update and query the Northwind database. Because there was only going to be simple validations needed on the data and mostly CRUD operations we opted to expose an Entity Data Model via ADO.NET Data Services like I showed before. This allowed us to get a secure service up and running in minutes.

We did make some minor changes to our old friend, the Northwind database. First, since we wanted to be able to look up order history for a customer when they emailed the sales reps, we needed to add an EmailAddress field to the Customers table (amazing that we didn't have that field before!). We also added it to the Employees table.

ALTER TABLE dbo.Customers ADD
    EmailAddress varchar(50) NULL
GO
ALTER TABLE dbo.Employees ADD
    EmailAddress varchar(50) NULL
GO

Then we populated the data with some customers and employees that were actually folks on our team because we need real email addresses to work with :-)

Next I created a new ASP.NET Web Application and added an ADO.NET Data Service and an Entity Data Model just like how I showed in this post. (You will need Visual Studio 2008 Service Pack 1 in order to get these new item templates.) For testing we set the service to allow full access to all the entities in the model -- we'll lock it down later. I also am passing detailed errors which we won't want to do once we're in production:

Public Class Northwind
    Inherits DataService(Of NorthwindEntities)

    ' This method is called only once to initialize service-wide policies.
    Public Shared Sub InitializeService(ByVal config As IDataServiceConfiguration)
        config.SetEntitySetAccessRule("*", EntitySetRights.All)
        config.UseVerboseErrors = True
    End Sub
End Class

One thing we did want to do is set up our data model so that it enforced constraints (i.e. there cannot be an Order without a Customer) but since some of our legacy data didn't specify all of these constraints we made the changes to the model instead, so that the integrity on all new data would be enforced through the service. This is often the case in projects, you cannot change the legacy databases but you still need to work with proper data models. So we changed the EDM so that all the entities were singular and not plural (Customer instead of Customers, Order instead of Orders, etc). We also changed the associations so that they were enforced and so that one to many collections were plural and the one-to-one were singular (i.e. Order has Order_Details collection and Order_Detail has Product reference). You can modify these from the Properties window of the Entity Data Model Designer.

Once I have the model and the data service code set up we can hit F5 and navigate our browser to the Northwind.svc and test the call to pull up all the customers (i.e. http://localhost:1234/Northwind.svc/Customers) just like how I showed in this post.

Now that we have our data exposed as a data service we can build the Office clients to interact with it just like I showed before here when we built a simple Excel client. Next post I'll show how we can use WPF controls in an Outlook Add-In in order to display the customer order history by querying the data through the data service.

Until next time...

ADO.NET Data Services - Intercepting Queries and Adding Validation

Beth Massi — Thu, 22 Jan 2009 07:53:00 GMT

Last few posts I've been building a WPF client against ADO.NET Data Services, if you missed them:

Today I want to show you how we can add validation or any other extra processing when data is queried from the data service as well as when we attempt to make changes to the data.

Ways of Querying a ADO.NET Data Service

First let's recap how we can query a data service. In our WPF client we've been taking advantage of LINQ but that's not the only way to send queries to the service. Because we're using the data service client framework we can write LINQ queries against the service and the client handles translating the queries into HTTP GETs. But we could also easily specify the raw URI's to send to the service. For instance, when we want to fill a combobox of categories ordered by CategoryName we could do this instead:

Imports System.Data.Services.Client
.
.
'Use the untyped DataServiceContext and pass URIs.
Dim ctx As New DataServiceContext(New Uri("http://localhost:1234/Northwind.svc"))
'Explicitly execute the the HTTP GET
Dim cats = ctx.Execute(Of Category)(New Uri("Categories?$orderby=CategoryName", UriKind.Relative))
'Display results in a combobox
Me.cboCategoryLookup.ItemsSource = cats.ToList()

In the code above the query is explicitly executed on the second line. You can achieve the same response by typing http://localhost:1234/Northwind.svc/Categories?$orderby=CategoryName in the address bar of your browser.

However one of the benefits of adding a service reference to our client is that it generates a proxy that inherits from the DataServiceContext that allows typed access to the entity sets that we're exposing from our service. This makes our code cleaner so we can write a LINQ query to do the same job instead:

Imports WpfClient.NorthwindService
.
.
Dim ctx As New NorthwindEntities(New Uri("http://localhost:1234/Northwind.svc"))

'Use LINQ to query the service instead
Dim cats = From c In ctx.Categories _
           Order By c.CategoryName

'Display results in a combobox. 
'The query is executed when we access the results (calling ToList())
Me.cboCategoryLookup.ItemsSource = cats.ToList()

Notice however that there is a subtle difference in this code that you should be aware of. When you write a LINQ query it never executes unless you access the results. In this case we're accessing the results when we call ToList() on the query. This is called deferred execution and it's something to be aware of. But if we look in Fiddler then we can see that the exact same HTTP GET is sent to the service: http://localhost:1234/Northwind.svc/Categories?$orderby=CategoryName

This also means that not every LINQ query can be translated into an HTTP GET. For instance, what if we just wanted to display a couple properties of the category in the combobox. You would think we'd be able to do something like this:

Dim cats = From c In ctx.Categories _
           Order By c.CategoryName _
           Select c.CategoryName, c.Description

Unfortunately if you try to do this you'll get a NotSupportedException thrown at you by the client framework because it can't translate the query into an HTTP GET. In this case you need to pull down the category entities you want first and then you can project over those to create a list of anonymous types with only the properties you specify. But remember that you need to "execute" the query against the service first and then query over the list that is returned. Here's a way to do this:

Dim cats = From c In ctx.Categories _
           Order By c.CategoryName

'Now project only the properties we want. 
' Call ToList() on the first query to execute the service call
Dim results = From c In cats.ToList() _
              Select c.CategoryName, c.Description

For more details on what is and isn't supported refer to this article.

Intercepting Queries

Now that we understand how queries work we can start messing with how they execute. :-) Say we want to query only the Products in Northwind that are not Discontinued. We could write the query against our data service that specified the filter like so:

Dim products = From p In ctx.Products _
               Where p.Discontinued = False _
               Order By p.ProductName

Or we could write the raw URI:

Dim productURI As New Uri("Products()?$filter=Discontinued%20eq%20false&$orderby=ProductName", _
                          UriKind.Relative)

Dim products = ctx.Execute(Of Product)(productURI)

But what if it was a new requirement of the entire system that nowhere should we be displaying discontinued products? If this is the case we should be enforcing this on our data service instead. This can be done using query interceptors on the service. The way we create these is we annotate a method on our service with the QueryInterceptor attribute. The method you write must follow these rules:

The method must have public scope and be annotated with the QueryInterceptorAttribute, taking the name of a entity set as a parameter.
The method must accept no parameters.
The method must return an expression of type System.Linq.Expressions.Expression(Of Func(Of T, Boolean)) that is the filter to be composed for the entity set.

The first two requirements are easy the third may be confusing if you've never played with lambda expressions. Basically what happens is you specify additional filtering to apply onto the incoming query via this lambda. So in order to append our condition that we should only be returning products that are not discontinued we can add this method to our data service:

Imports System.Data.Services
Imports System.Linq
Imports System.ServiceModel.Web
Imports System.Linq.Expressions

Public Class Northwind
    Inherits DataService(Of NorthwindEntities)

    ' This method is called only once to initialize service-wide policies.
    Public Shared Sub InitializeService(ByVal config As IDataServiceConfiguration)
        config.SetEntitySetAccessRule("Products", EntitySetRights.All)
        config.SetEntitySetAccessRule("Categories", EntitySetRights.All)
    End Sub

    <QueryInterceptor("Products")> _
    Public Function FilterProducts() As Expression(Of Func(Of Product, Boolean))
        'Only return products that are not discontinued
        Return Function(p) p.Discontinued = False
    End Function

End Class

Now we can write our queries without specifying the additional filter on discontinued and this will not be sent to the service from our client in the HTTP GET but will be executed against our database. The query interceptor will execute regardless if we write a LINQ query or feed it the raw URI.

LINQ Query:

Dim products = From p In ctx.Products Order By p.ProductName
Me.ListView1.ItemsSource = products.ToList()

URI:

Dim productURI As New Uri("Products()?$orderby=ProductName", UriKind.Relative)
Dim products = ctx.Execute(Of Product)(productURI)
Me.ListView1.ItemsSource = products.ToList()

Pretty slick. You could of course do other processing here first. And you can also specify your own additional service operations as well by attributing them with a <WebGet> attribute. More on those in a later post.

Validation with Change Interceptors

You can also add methods to your service that will execute when changes are submitted. This allows us to add validation or other processing onto the data being submitted to the database. You do this by attributing a method in the data service with the ChangeInterceptor attribute. A change interceptor will pass the entity being saved and a parameter that indicates what update operation is being performed. For instance, say we want to put a validation on our ProductName so that users cannot submit empty product names to the database. We could write a method in our data service like so:

<ChangeInterceptor("Products")> _
Public Sub OnChangeProducts(ByVal p As Product, ByVal ops As UpdateOperations)
    If ops = UpdateOperations.Add OrElse ops = UpdateOperations.Change Then
        'Do not allow products with empty names
        If p.ProductName = "" Then
            Throw New DataServiceException(400, "Product name cannot be empty")
        End If
    End If
End Sub

When we throw a DataServiceException we can specify the HTTP status code and the message to return to the client. 400 indicates "Bad Request" and we pass the message on what the problem was. So if we try to submit a new or existing product with no product name we will get an HTTP error as seen in Fiddler:

This is what's happening on the wire when we call SaveChanges and the exception is caught on the client. This prevents our data from being invalid no matter what client it's coming from. However this isn't that user-friendly to say the least. If we're building a smart client it's much better to put this type of validations on the client as well.

We can do this in our WPF client by extending the Product partial class and implementing IDataErrorInfo and adding our validation. On the WPF client create a new class called Product and place it in the same exact namespace as the NorthwindEntities data service client proxy that is generated for us when we add the service reference. It's called NorthwindService in our case. Then we can overwrite the partial method OnProductNameChanging to do the client-side validation. This method is called from the ProductName property setter in the generated entity on the client. Here's an example of how we can collect validation messages on the Product.

Imports WpfClient.NorthwindService
Imports System.ComponentModel

Namespace NorthwindService

    Partial Public Class Product
        Implements IDataErrorInfo

        Private Sub OnProductNameChanging(ByVal value As String)
            If value Is Nothing OrElse value.Trim = "" Then
                Me.AddError("ProductName", "Product name cannot be empty")
            Else
                Me.RemoveError("ProductName")
            End If
        End Sub

#Region "IDataErrorInfo Members"
        Private m_validationErrors As New Dictionary(Of String, String)

        Private Sub AddError(ByVal columnName As String, ByVal msg As String)
            If Not m_validationErrors.ContainsKey(columnName) Then
                m_validationErrors.Add(columnName, msg)
            End If
        End Sub

        Private Sub RemoveError(ByVal columnName As String)
            If m_validationErrors.ContainsKey(columnName) Then
                m_validationErrors.Remove(columnName)
            End If
        End Sub

        Friend ReadOnly Property HasErrors() As Boolean
            Get
                Return (Me.Error IsNot Nothing)
            End Get
        End Property

        Friend ReadOnly Property [Error]() As String _
                                 Implements System.ComponentModel.IDataErrorInfo.Error
            Get
                If m_validationErrors.Count > 0 Then
                    Return "Product Data is invalid"
                Else
                    Return Nothing
                End If
            End Get
        End Property

        Default Friend ReadOnly Property Item(ByVal columnName As String) As String _
                                         Implements System.ComponentModel.IDataErrorInfo.Item
            Get
                If m_validationErrors.ContainsKey(columnName) Then
                    Return m_validationErrors(columnName).ToString
                Else
                    Return Nothing
                End If
            End Get
        End Property
#End Region

    End Class

End Namespace

Notice that the client-side IDataErrorInfo properties are declared as Friend (internal) so that they are not serialized back up to the server. Next we need to make sure the bindings in the XAML of our ProductDetail form is set up to display the error.

<TextBox 
 Text="{Binding Path=ProductName, ValidatesOnDataErrors=True}"
 Height="25" Name="TextBox1" Width="180" Margin="3" HorizontalAlignment="Left" />

You can also add a validation ErrorTemplate if you like. I've shown this validation technique with WPF here before. So when we don't enter the ProductName on a product we can display the problem to the user right away without bothering our data service:

Check out the updated sample on Code Galley, in there I also implement IEditableObject so that users can cancel out of editing of the products.

However, the fact that we have to put rules in two locations in our code is a total drag. If we could type share the entity partial classes on the server and the client then we could write this code in one place and run it in both the client and the server. This is why if you have complex business rules you're probably better off creating your own DataContracts and implementing your own WCF services. However, applications like this that have simple validation and heavy CRUD requirements make it a perfect candidate to use ADO.NET Data Services.

Next post I'll show how we can query and edit tabular data inside of an Excel client and post changes back to the data service.

Enjoy!