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.
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.
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