I have been developing with ASP.Net since it debuted. Before that I was doing windows form development with VB and classic ASP web development. The advent of ASP.Net was phenomenal for me and my team. The web forms model allowed our team to continue using the Windows event driven model over the web and allowed us to take our web development to a new level than classic ASP. We quickly dispatched of our windows development in favor of the simple deploy / update model and gladly left the dreaded PC install / update nightmare.
Fast forward many years and ASP.Net matured quite a bit, Windows Forms had click once and all sorts of other goodies in the framework. Now MVC. My experience with MVC up until this point had only been my reading in the Gang of Four book and the occasional blog entry. While all this was going on I had (and still am) been on a mission to improve my programming skills. The majority of this was and has been reading, reading, and more reading. I started trying out test driven development with a side project of mine. The project was web forms based. I was greatly encouraged with TDD but had read all the difficulties with TDD and web forms. I had just begun this side project and decided why not make the switch to MVC? So I did.
Along the way, I have had a lot of "aha" moments. Here’s some of them:
Web forms code behind faked me out. I thought I had good separation of concerns. Or I really abused the code behind file but I thought I was doing right.
For quite a while I knew large code behind files were not healthy. I had been working as best as possible to decrease the code in them. However, with my MVC journey I think I have come to see just how unhealthy large code behind files are and just because the code was not in the same file as my html did not mean I had a strong separation. MVC by it’s nature encourages good separation and all the books and blog entries I have read show this by default. In the web forms world I had to seek this out (not so much today but definitely in the early days and habits can be hard to change).
I’m having data source withdrawals and View State withdrawals.
I’m nearly over it now but this was a big hurdle for me. It’s amazing how reliant I became on this but it shouldn’t be too much of a surprise since this is the magic of Web Forms.
I'm loving having control back of the HTML and the HTML is actually readable now.
So why would I want the control back. Simple, because I can easily have it back now and the trade off to me doesn’t really feel like a trade off. MVC is far more bare bones by design but I still don’t feel like I am back at the classic ASP spaghetti code. It’s this bare bones nature that I am really digging. I have a lot more control over everything and even though I may not want to control a lot I know I have the option to. I do miss at times the "drag and drop a control unto the canvas and go" mentality but with jQuery and HTML helpers I am missing it less and less as I become more proficient.
Testing? Ya, I did that. It's F5 right?
MVC was not my start on considering better ways to test but everything I read and worked with on MVC had testing involved all the way. Every book I have read, every beginning MVC blog entry has testing intertwined. My first attempts at unit testing was with a web forms project and I was absolutely convinced it would make me a better developer, faster developer and create more maintainable code. However, with web forms, testing for me and many I suspect was changing some code and hitting F5 to run the application and manually test. With a little unit testing / TDD under my belt I have come to see how much more efficient it is to "F5 testing".
MVC permeates with the idea of unit testing and that’s by design. I have much to learn on my testing journey but it has already paid dividends for me that has me convinced it’s an important tool in my toolset.
I am working in harmony with the HTTP protocol now.
I mentioned one of the reasons I liked web forms is that it allowed me a very easy transition from windows forms development. As much as I would like to say I understood how the web really worked underneath the hood I know now that I didn’t. Yes, I knew it was stateless and all that jazz but with web forms I was abstracted away from the way the web worked.
When I started learning MVC it became painfully obvious how much I had forgotten and/or didn’t really understand about how the web works. I am still tripping over this while I continue my MVC journey but I am happy to say that the knowledge gained in understanding more deeply how the HTTP protocol really works is making me a better web developer. “Working in harmony” is a paraphrased quote from "Pro ASP.NET MVC Framework" by Steven Sanderson.
I am enjoying my MVC journey and look forward to becoming extremely proficient with it. I will also admit that much of my 'aha' moments are not because of Web Forms, rather they were mainly a result of my own lack of exploration into what was possible and what was out there. I was too busy keeping my head down and firing out widgets instead of really trying to hone my craft at all times while spitting out widgets. This has changed for me now. I have an extremely strong desire to be a real craftsman and not just someone who can bang on a keyboard.
Web Forms is a great tool and I imagine I will continue to have it as a tool in my toolset for a long time to come along with MVC.