Wednesday, December 12, 2007

I've done this demo many times in conference and user group sessions. Someone on the ADO.NET forums asked how to do it and I thought I would just do a quick tutorial with screenshots.

What this Tutorial does is demonstrate how to create and use a data source from a particular entity in the model. I'm just doing simple drag and drop and no filtering or anything here with the goal of just a quick basic walkthrough for getting started.

Start by creating a Windows Application.

Add an Entity Data Model.

Select Data from the menu and choose Add New Data Source

In the first page of the wizard, choose Object as your Data Source Type.

The next screen of the wizard will show the namespaces in the current solution. Open up the namespace for the application

then choose the entity which you want to use as a Data Source. I will pick customer.

Then you can Finish the Wizard.

Now to get easy access to the datasource, go back to the menu and choose Show Data Sources from the Data menu.

The DataSources Window will be placed in your IDE in it's default location. Mine docks with the windows on the left.

When it's not pinned it gets tucked away with the others. You can undock it and put it wherever you want.

I can now drag and drop the customer data source onto the windows form to get the automatic DataGridView and Navigation toolbar (this is normal behavior for DataSource and not specific to Entity Framework).

There are a few more steps to actually getting user interaction with this. You need to populate the Binding Source and if you want to edit, you'll need to add a little code to the save button on the toolbar.

You'll need to enable the BindingNavigatorSaveButton (just click the save icon on the navigator toolbar and change it's Enabled property to True). Additionally, you'll probably want to format the grid which you can do easily from it's SmartTag and more thoroughly through the properties window.

Here's what the code behind looks like in my form enabling me to view, add, delete, edit and save data.

Imports WindowsApplication1.AdventureWorksLTModel
Public Class Form1
  Private aw As AdventureWorksLTEntities
  Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    aw = New AdventureWorksLTEntities
    CustomerBindingSource.DataSource = aw.Customer.OrderBy(Function(cust) cust.CompanyName)
  End Sub

  Private Sub CustomerBindingNavigatorSaveItem_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles CustomerBindingNavigatorSaveItem.Click aw.SaveChanges() End Sub End Class

Note that because the AdventureWorks Customer table has the following constraints: ModifiedDate must be a valid date value and the PasswordHash and PasswordSalt fields cannot be Null, I have extended the entity class to take care of these things when SaveChanges is called.

Wednesday, December 12, 2007 12:25:30 PM (Eastern Standard Time, UTC-05:00)  #     |  Comments [5]  | 
Tuesday, January 08, 2008 3:21:50 PM (Eastern Standard Time, UTC-05:00)
Hey Now Julie,
I really enjoy your blog & this post was very simple yet informative.
Thx 4 the info,
Catto
Tuesday, January 29, 2008 1:37:19 PM (Eastern Standard Time, UTC-05:00)
Hi Julie,
I've really benefited from your entity framework blogs here as well as your posts on the msdn forums. In this post, I noticed that you declared AdventureWorksLTEntities as a class member. I couldn't find any full documentation on the ObjectContext class (I assume this is because its still in Beta), but for the DataContext which is the equivalent in LINQ to SQL, Microsoft states:

"In general, a DataContext instance is designed to last for one "unit of work" however your application defines that term. A DataContext is lightweight and is not expensive to create. A typical LINQ to SQL application creates DataContext instances at method scope or as a member of short-lived classes that represent a logical set of related database operations."

Personally, your way appears to be more convenient as I cannot think of a way to do what you've done without declaring it as a member class, but do you know:

1) If the above statement/suggestion from Microsoft applies to the ObjectContext class

2) Any reasons for the above statement/suggestion

Thanks again for all of your work.

Ean


Ean
Tuesday, January 29, 2008 1:46:17 PM (Eastern Standard Time, UTC-05:00)
Thanks Ean.

You've made a good observation and a logical one. This is something that I had to be convinced to do myself at first. ObjectContext and DataContext are actually different in this light.

The ObjectContext is there to manage the entities. Connecting to the database is a small part of it's job. With clientapps, the ObjectContext was designed to hang around, so that even after getting the data from the db (and closing the db connection) it still needs to manage the entities (epecially for change tracking).

Check out this post where I quoted Microsoft's guidance on this:

http://www.thedatafarm.com/blog/2007/12/21/SomeGreatEntityFrameworkGuidanceAboutPerformanceInClientApplications.aspx

hth

julie
Julia Lerman
Tuesday, January 29, 2008 2:35:24 PM (Eastern Standard Time, UTC-05:00)
Thanks Julie. That was exactly what I wanted to hear since I wasn't looking forward to trying to find an alternative. My question was actually related to a Winforms app. Next time I'll try to be more specific as this situation shows how important that can be.
Ean
Tuesday, January 29, 2008 4:03:44 PM (Eastern Standard Time, UTC-05:00)
I guessed that you were talking about WinForm apps since that was the focus of the blog post! ;-) WinForm apps definitely falls under the umbrella of "client apps", although I could have been clearer and said "client side apps".
Julia Lerman
Comments are closed.