Frustrating Problems and Single Word Solutions

For the last few days I’ve been struggling with a problem in the application I’ve been building that would throw no exception but simply wouldn’t produce the results I expected. When I’m met with a problem like that, it really tests your debugging skills. Why isn’t it producing what I want? Where do I start looking for issues? Is it the view? Is it the model? My approach is to start from the beginning, the Index action in my home controller, and watch the application move from there until the problem occurs. After that, I can jump back to just before it happened and zero in on it.

My application’s purpose is to keep track of the TV Shows a user may be following. The user enters key information about the show, name, genre, number of episodes in total and the number of episodes seen and then the application will display that on the main page. The user can then see at a glance where s/he is up to in each series. The main model is the Show object, with the genre objects being secondary. Each show object has a reference to a genre object and in future, the genre object will have a list of shows that reference it so the user can select a genre and view all shows of that genre. My expectation was that the Entity Framework would load the genre object into memory whenever it loaded a show object because of the reference from the show object to the genre object. I thought that if there was no genre object, the framework would execute a query and add it. From what I can understand online, this is called Lazy Loading. More on this later.

As I zeroed in on the problem area in my application, I noticed that my application seemed to be dumping what the user entered in the Genre field on Show creation or editing. There weren’t any exceptions or hints as to why this field in particular was being dumped but after some more investigation I found that, for whatever reason, the genre wouldn’t be permanently written to the database and when the database context was disposed of, the genre would go with it. I posed the question to StackOverflow and most answers told me that I needed to add a hidden field that held onto the id of the genre so the view knew to pass the genre back to the controller. This didn’t fix the problem, but it did help. When I stepped through the debugger after making the change, my Edit action wouldn’t enter the loop that made changes to the database because the ModelState.IsValid property was now false. A clue!

Unfortunately, the clue wasn’t very useful. The ModelState class’ IsValid property was false because the genre’s ID property was null, something I thought the database should automatically generate because it was the primary key for the genre table. My only clue was basically just reminding me of what I already knew, the genre object wasn’t being saved to the database. How was I going to figure out why? It’s problems like these that I would avoid if I knew exactly how the framework worked but with something as large as ASP.NET MVC, that would take quite some time.

My only hope was that I would accidentally stumble over something while searching for examples of how others had implemented something similar to what I was doing. Luckily, the internet is full of examples and I found this MSDN article that explained loading related data using the Entity Framework. According to the article, Lazy Loading is driven by the EntityCollection and EntityReference classes and won’t be available when you’re using Plain Old CLR Object (POCO) class (like I was) unless you mark the navigation properties as virtual or Overridable which will trigger the Entity Framework dynamic proxy behavior where it creates a runtime proxy that allows your POCOs to lazy load as well. Lo and behold, setting the navigation property in my Show class (the reference to the genre object) as virtual, all of my problems disappeared. The genre field in the create and edit views were no longer being discarded and it was correctly being displayed in the details view.

The problem I had been struggling with had been fixed with one word.

P4040106edit-3.jpg

 
0
Kudos
 
0
Kudos

Now read this

Learning by drowning

There’s no better way to learn than to throw yourself into the deep end and try and swim. Recently I did just that and started working on an MVC app to get some practice building something from start to finish with as little help from... Continue →