Things learned when moving to MVC from Webforms

  • Friday, March 31, 2017 3:31 AM EST
  • Last Edited: Friday, March 31, 2017 12:02 PM EST

I love working on asp.net webforms sites because I am so used to event driven concepts and methodology. Coming from java and winforms background, asp.net webforms was easy to grasp. Last year, I felt I needed to learn MVC because most developers I know have switched to it and they say they love it. With more and more tutorials out there getting to MVC I knew I had to learn or be left behind. My need to learn led me to sign up and learn from Pluralsight. They have a ton of resources there that has helped me give a general perspective of MVC. But I am a hands-on person and you can only make me stay a few hours watching a how-to video before I get distracted with Netflix. After a few months of waiting, I finally got my wish and I have been involved in multiple projects that requires me to use MVC.

 This is a list of items I have learned while going through and may help out other webforms developers who are transitioning to MVC or may want to learn it.

 1. MVC makes you go back to HTTP basics.

 Webforms has spoiled me so much to event driven thinking. All values posted/submitted are saved in a ViewState and because of it, it feels like writing a desktop application (winforms).  HTTP is stateless and you have to go back to that kind of thinking.

You have to remember that when you do a post, you have to save your values somewhere like in a session to show the posted values in a Review/Confirmation page.

 2. Say goodbye to webcontrols.

 Webforms web controls make it really easy to call a server function without writing any javascript. But the biggest obstacle I had when getting html templates from non-asp.net interface developers was integrating their stuff to asp.net web controls. They love using <button> tags or tables with <thead>. The way I handled this issue was to ask them to use the right html tag, create a custom control or hack my way so their html will work. This was time consuming.

 With MVC, you are free to use whatever html you like.

Note: In webforms, you can still create a page free from web control but it defeats the purpose of the technology. 

 MVC does have similar ideas to webcontrols. They are called html helpers. These are a lightweight version of webcontrols and do not add extra html (with a few exceptions) to it. Best thing is no more javascript events at all! This forces you to go back and learn javascript which isnt a bad thing.

 This said, webcontrols are a time saver if you know how to use it. The gridview for example already has prebuilt edit, delete functionality and all you need is call the service to change in the data repository. With MVC, you will have to write the javascript yourself to make a table mimic the functionalities of a gridview. There are jQuery libraries out there that will help you do this faster. I personally prefer doing the javascript myself because it keeps me sharp and eventually, you can create a JS library to reuse your code that resembles the functionalities to a gridview. Eventually, when you start learning AngularJS, this will hasten the process even more so I do not see why it will be a big obstacle.

 3. Convention over configuration.

 In MVC, to match a controller to a view, I just had to keep in mind that I had to name it the same to the controller method name and place it in a folder that is the same to the controller (Note: this one is most of the time true, eventually you will learn that you can return other views without this structure) . It took awhile for me to get this because I did not get why it just worked. How in the world did asp.net know it was to match it with this page? I was used to seeing every ASPX page is a .cs file behind it. This is where the convention over configuration (https://www.danylkoweb.com/Blog/aspnet-mvc-convention-over-configuration-BU) came  in and ever since then, I just knew it worked. This holds true to the urls as well. The controller name is the first path of your url and the controller methods under it is the second level. (Note: again, like views, you can manipulate not to follow this)

 4. Url paths are not folder structures.

Without using web.config rewrites and redirects, finding the .aspx file in webforms was a breeze. You just had to follow the url and the folder path follows this structure too. An Example is www.thisismysite.com/home.aspx is equal to seeing Home folder with Index.aspx inside it or Home.aspx in the root folder while www.thisismysite.com/home/secondlevel.aspx is under Home folder with SecondLevel.aspx file inside this folder.

MVC on the other hand requires you to follow the controller then find the method under the controller to go to second level. It gets a little bit more complicated if you have 5 or more levels in your url. What gets harder is if you are not familiar with the site, and so you have to read the url routes to go find the controller or view.

Emphasizing on item #3, convention over configuration, you actually have  to configure if you want a folder structure with your views with multiple levels. MVC strictly follows that you only get one level of folder structure. Using our previous example of www.thisismysite.com/home/secondlevel, your secondlevel page is found under Views > Home > SecondLevel.cshtml which is the same with webforms. But if you reach 3rd, fourth level, ASP.Net MVC will not understand Views > Home > SecondLevel > 3rdLevel.cshtml and so on. Again, convention over configuration.

  

Additional items coming soon…

comments powered by Disqus