Practical ASP.NET

Using the Entity Model to Create an ASP.NET Page

What's one test of a new technology? Seeing whether you can use it with the old technology.

Over the previous two columns ("Integrating Entity Framework with an ASP.NET Web Site" and "Extending an Entity Framework Model -- and Some Limitations"), I've built a simple Entity Framework (EF) entity model using the Northwind database that consists of Customers, Orders and OrderDetails entities. My goal is to see how far I can take EF and Dynamic Data to create the kind of pages that I build in the applications for my clients.

Doing the Same Stuff
In this column, however, I want to do something simpler: Can I use EF with the technology I already understand? For instance, the sample page that I want to create has a drop-down list at the top that allows the user to select a company. Implementing this with EF is both easy and a little familiar.

I start by dragging an EntityDataSource onto the page and, from its SmartTag, select Configure Data Source. In the Configure Data Source, from the Named Connection drop-down list, I select the name of my model. The resulting dialog lets me select the entity that I want (Customers, in this case), apply a filter (useful if I've used inheritance), decide which fields I want (both CustomerId and CompanyName), and decide what updates I want to support (in this case, none). With the EntityDataSource configured, I attach a drop-down list to the EntityDataSource just as I would with any of the other DataSources.

But I wanted to limit the list of customers to customers in specific Regions. I returned to my Entity Model and added an Entity mapped to a table that lists all of the Regions in the Northwind application. I also added a Region property to the Customer entity which I mapped to the Customer table's Region column. I rebuilt the Web site to pick up the new entity, dropped an EntityDataSource onto my page and configured it to use the new Region Entity. Another few clicks put a drop-down list on the page that I tied to the Region DataSource.

This is all good because it means that a) I don't have to get everything right the first time, and b) adding new functionality goes quickly.

To limit the customers displayed in my Customer drop-down list to the region selected in the Region drop-down list, I go the Properties Window for the Customer EntityDataSource. In the Properties window, I select the Where property and click on the build button that appears (the button with the three dots) which displays the Expression Editor dialog. In this dialog, I click the Add Parameter button to add a parameter and configure it.

For this scenario, added a parameter to my Customer EntityDataSource and pointed it at the Region drop-down list. Rather than attempt to write a Where clause to use this parameter, I just checked the Autogenerate option to get the DataSource to write its own Where clause. I did have to name the parameter myself rather than pick a property (or column) from a drop-down list.

But I also wanted to use AJAX. So I dropped a ScriptManager and an UpdatePanel on the page, dragged my two drop-down lists into the UpdatePanel and ran the application. Everything worked as expected: Selecting a Region in the first drop-down list limits the list of customers in the second drop-down list.

But, of course, other than using some new controls (and working with the Expression Editor), I haven't really used the new technology. In fact, I actually had to avoid some EF functionality. Had I created an association between the Customers and Region entities, I would have to omit adding a Region property to the Customers entity (you can't have a column in the table that's referenced both as a property and as part of an association). Without a Region property on the Customers entity, I wouldn't have been able to create a parameter in the EntityDataSource that used the Customers' Region property to limit the list of Customers.

So the next step is to start actually using the technology the way it was intended. That's for my next column.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.

comments powered by Disqus

Featured

Subscribe on YouTube