5 Major Mistakes I Made With ASP.NET MVC

Being eager to dive into something so new rather quickly can be a curse and a blessing. Today, I cover five mistakes I made when programming with ASP.NET MVC.

When you start something new, it can be exhilarating working with the shiny new toy, but at the same time, you make newbie mistakes because it's so new and you need experience to make it work for you.

It's all part of the learning process. Sometimes you need the Gibb's Headslap to help you focus more.

However, there are times when you get comfortable and you still make mistakes with the code. Just recently, I made one of those newbie mistakes, but I caught myself and was able to fix it relatively quick before I fell down the rabbit hole.

As you dig more into MVC, you'll run into these at one point or another.

Here are my top 5 that I've experienced over the years that bit me in the butt.

1. Moving Forward Too Fast With A New Release

While this is common with just about everything related to technology, this mistake was made back in 2010.

I was working with the ASP.NET MVC 2 Preview 2 and built my entire CMS based on that preview release. I figured, heck...what could go wrong?

Well, when ASP.NET MVC RC2 came out they removed the MapAreaRoute. Since this was a cornerstone for how I was writing a modular CMS and found out that it was removed, now I needed to rethink (and rewrite) how my modular CMS was going to work.

I've always said that when a new version of something comes out, you should always "let the scouts take the arrows." Basically, let the testers see if everything is ok before giving the go-ahead to start using it.

Even though ASP.NET MVC 6 is moving along, I will still be using ASP.NET MVC 5 for now...until 6 has been in the wild for a little longer. ;-)

2. Placing Everything In An HtmlHelper

The HtmlHelper takes a lot of the coding away from your View so your Views don't have conditional statements and it keeps them cleaner and easier to read.

But when it comes to HtmlHelpers, one of the mistakes I've made is writing too much HTML as code.

For example, I mentioned before that I had a need to display media based on their types and show that media's properties. That would mean I would have to write all kinds of TagBuilders focusing on each Media type.

With approach 2, I was able to off-load everything to the HTML by checking quickly what the media type was and loading the appropriate media type.

It took 200 lines of building HTML using TagBuilders down to < 10 lines of code AND I didn't need to compile when I made a change to the HTML.

3. Using ActionLink on Views

One of the things I always wondered when I first started with ASP.NET MVC was how to create a link in a View.

Of course, I found out you need the ActionLink HtmlHelper to create your links.

With that knowledge, I started a new MVC project for a client. I started using ActionLinks across all of my Views. There were ActionLinks all over the place.

Then they dropped the bomb.

"Let's change the URL to something else."

I learned this lesson the hard way. I had to go into every single View to change the controller and action name.

That's when I decided to consolidate all of my URLs in one location using UrlHelpers.

When I need to change the location of a link, I go to one place and change it and it changes everywhere.

4. Keeping Your Controller Clean

At first, I thought controllers were used for containing all of the code to send back and forth to the Views and that was it. As I continued to write "controller code," each method got a little longer.

Not as long as one project that I worked on though.

I was asked to look over one particular MVC project and see if there were any problems with it. The controller contained a lot of action methods (at least 30) and each method had at least 50 lines of code to it.

Of course, there was duplication of code throughout the entire controller, but it desperately needed refactored.

As mentioned before, a controller's only responsibility should be that of a traffic cop: Process the data coming in and direct the flow to the appropriate place.

I learned to keep the code in the controller to a minimum. 

5. Using ViewBag or ViewData for passing data (and no Session!)

Passing data back to the View was a simple task when I first started with MVC. You load the collection in the controller, and magically, it is accessible through the View.

Call me spoiled, but the one hangup I had with the ViewBag or ViewData is that I didn't have IntelliSense on the View.

If you didn't specify a model at the top of the View or used ViewBag or ViewData, there was no way to tell the type of data returned to the View.

Again, I learned this the hard way.

My Views were becoming really messy with all of the casting of objects sprinkled throughout. Ugh!

Then I realized that you could pass complex object types through the View action result in the controller (as mentioned here).

And for those who are saying under their breath, "Why not just use Session?", this is just as bad. It's still a string collection and it's so 2005.

Luckily, I'm not the only one who feels this way about Sessions.

Conclusion

I'm providing these mistakes to show that everyone can make mistakes when programming. It just takes time to gain experience to understand when something needs refactoring.

As one of my colleagues used to say to me, "refactor, don't ref*ckter it up"

Have you made any mistakes with MVC? Share it below in the comments.