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 prebaked code on the internet or functioning sites that come as templates with Visual Studio. I couldn’t tell the difference between the empty template and the basic template so I chose the latter in the hopes that I’d avoid having to write the files I don’t understand yet (like the web.config file) but still have to add all the functionality. I had a vague idea for a site I wanted to make so I created the project and began.

I stared at the blank project for at least thirty minutes. Where does one start? My project was to build a site that I could use to keep track of how far I was through the TV shows I was watching. I assumed it would be a simple CRUD app, but even that I didn’t know how to start. It sort of reminded me of when I start a blog post and I sit there, staring at the empty white, waiting for the words to come to me. The thought of a CRUD app was the trigger that got me started. I began with C, create.

I created a class with basic CRUD functionality using a canned Visual Studio routine. I plan on revisiting that to make sure there’s no magic going on that I’m glossing over but for the meantime I just wanted to get something working. Once the class has been created, I started debugging. I noticed that, after creating the views, the basic template had some CSS styling and a basic HTML skeleton in place so I didn’t need to create those to see my site. Again, I plan on doing that myself in another project or a redesign of this one at some point for practice but for now, I figured I had bit off enough.

Looking back, I have no idea why simply creating the create action took so long. It isn’t all that complex but there are little details that spring up as you’re creating it that make you think about the design of your application or force you to do some research and read some documentation. One such detail was the “Watching State” property for each of the shows. In my application, the user enters in the name, genre, total number of episodes, the number of episodes they’ve seen, the watching state of the show (whether they are watching it, planned to watch it, put it on hold or dropped it) and description for each show that they are following. The watch state is a simple drop down box with a list of each of the states which corresponds to an attribute of each Show object in my database. I initially created the list of items in the constructor of the Show class (my model class) but I’d get an exception when I tried to use it in the CSHTML file for the create page saying that I needed an object reference. My first reaction was to make the list static so I could access it without an object reference. This helped in that I didn’t get any exceptions but now whenever I clicked on the dropdownlist I was greeted by multiples of my list. Confused, I inserted some breakpoints in my code and tried to figure out why I was getting so many duplicates in my list.

Although unexpected results can be frustrating, this particular bug was a good one for my understanding because I don’t know much about what the ASP.NET MVC framework is doing behind the scenes. By watching the execution of my app steb-by-step, I found out that the index action in my home controller created a list of all the shows in the database. When Shows.ToList() is called, my code jumped into the Show class’ constructor as many times as there were show objects in the database and thanks to my Watching State list being static and populated in the constructor, I was getting a list that was essentially three or more, depending on the number of shows, identical lists merged together.

Figuring out how to fix this was another issue. At first I didn’t understand why I had so many duplicates in my list. After figuring out the cause, I didn’t know what I could do to fix it. Where else could I put the list? After some reading, I found an answer on the incredibly helpful StackOverflow that said,

With static classes in C# there are two potential dangers if you’re not careful:

• The requested resources will not be freed until the end of application life
• The values of static variables are shared within an application. Especially bad for ASP.NET applications, because these values will then be shared between all users of a site residing in a particular Application Domain.

By populating the list in the constructor, I was just appending the same options to a shared variable and then using it for my listbox. In the end, I settled on creating a static property that only had a getter which would return a new list that I initialised inline. It isn’t pretty, but until I figure out a better way of doing it, it will have to do. At least it works!