As I mentioned in an earlier post, my current project combines Entity Framework, ASP.NET MVC3 and jQuery mobile. It’s my first real mobile-device focused project, and I’m not too concerned about scalability at the moment (at least not on the first cut – I will probably refactor later). My main interest right now is in seeing how the different technologies fit together, but especially in getting some hands-on experience with the shiny new jQuery mobile framework. Along the way, though, I’ve used MVC3’s EF scaffolding for the first time – and have a few thoughts to share, along with a couple of gotchas.
I started out with a Model First Entity Framework project (see this article by Doug Rehnstrom if you’re not familiar with this approach). The real application has a separate data project and is moderately complex, but I’ve recreated a simplified bit of it here to illustrate the advantages/disadvantages of the approach.
Here is a (very simple) part of the EF model. There are two tables – one for beverages (e.g. Bourbon, Orange Juice) one for types of beverage (e.g. Spirits, Fruit Juice).
I used this model to create the database (as per Doug’s article), then tried to use it to scaffold the ASP.NET MVC application. I right-click on the controllers folder and select Add Controller.
(Minor) Gotcha Number 1: I get an error saying there are no model classes:
So – first we need to do a build. Now we get our dialog with model classes. I fill out the dialog for a scaffolded BeverageTypeController, and tell it to use the cocktailsContainer as the data context (‘cocktails’ is the model/database name).
Now when I click Add, I get a controller complete with read/write methods. I also get matching Views:
There are some serious pros and cons here. The biggest pro, of course, is how fast all this is. In no time at all, I’ve created an object model, a database and a whole set of controllers and scaffolded views. So – this is pretty RAD for ASP.NET MVC. And that, of course, is also the con. There is no proper separation of the layers. The controller contains all the data access code – definitely NOT what we teach you to do in Learning Tree’s ASP.NET MVC course, Building Web Applications with ASP.NET MVC.
But still, for my purposes on my current project, this lets me get up and running quickly so I can focus on the mobile part of the application. I can always refactor later on and create a proper n-tier application. There is, however, one remaining gotcha, and it’s a nasty one.
Gotcha Number 2: The scaffolding code causes problems with SelectLists.
The problem is that the scaffolding code uses the name of the selected property as the ViewBag key. This means, for example, that the list of BeverageTypes inside the Beverage page is held in the ViewBag.BeverageTypeId property. That’s a problem, because beverage.BeverageTypeId is defined as the selected item – and that upsets the dropdownlsit, which looks in a number of places for the selected item and gets confused if the key is the same as the property name.
Unfortunately, this confusion ends up wiping the selected value, as the following illustration demonstrates (orange juice is obviously not a spirit!):
The solution is to change the name of the ViewBag property in both the controller and the view:
Here’s the amended controller:
And here’s the amended view:
And this time your selection will be respected:
So, overall, the EF scaffolding is a very nice RAD feature. It has a couple of glitches, but it’s allowed me to get a LOT of work done very quickly. I wouldn’t use it for the final version of a project, but in this case it’s just what I need to test out the viability of my application design – I can always refactor it later on if I decide that my prototype looks promising.
For other related information, check out these courses from Learning Tree: