Adopting ASP.NET MVC: WebForms Damage Control
31 05 2009I recently retweeted a comment from Brad Wilson about how much damage WebForms has done to the typical developer’s knowledge of the web. I thought he had summarized it quite while and I wasn’t going to offer my thoughts on the matter but it’s been on my mind for quite a while and I feel like it’s time for me to weigh-in on this situation. It turns out that I have quite a bit to say.
Before I begin, I will note that I have been working with WebForms since the early days and have truly appreciated the rapid rate in which the platform allows you to develop certain applications (or pieces of applications).
The individual adoption of ASP.NET MVC is no easy thing, so it should come as no surprise that an organizational adoption of ASP.NET MVC is not a walk in the park. The WebForms platform does a great job at providing a set of Rapid Application Development tools to get your job done quickly and somewhat easily…depending on the task and the team you’re working with. When you begin running into rendering problems or third-party integration problems, a deeper understanding of the toolset is required and unfortunately most entry and junior-level developers just don’t have it.
Individual Adoption
The transition probably isn’t the same from one person to the next, but I can make some generalizations based on my personal experiences introducing the change and helping through various online communities. These generalizations have been mostly made by helping people transition as they tackle more real-life applications using MVC. As with any new technology, I strongly recommend the “Hello, World!” approach but not everybody agrees with me.
I wanna go fast!
The initial introduction to the concepts seems to go over quite well. You’re not sure if they understand it or just want to get their hands dirty by playing with it. They’re not sure if they understand it either…but it’s a new technology and they’re excited to get their hands dirty.
Where’d my magic go?
The first question is asked: “How do I access my <some control ID> control? It’s not showing up in intellisense.” Be careful here, you’re about to tell them everything they know about the web is a lie! You carefully deliver the bad news and show them some examples of posting information.
So…I have to reinvent the wheel?
This is a question that I get a lot and it’s taken me a while to understand how to respond to it. Now, it may be different with every person but I’ve found that this question gets asked for a few reasons that all seem to boil down to this: the purpose of the ASP.NET MVC framework has not been properly explained and a proper comparison between MVC and WebForms has not been made. It should be clear that MVC is an alternative to WebForms (not a replacement) and that the entire development approach is different.
“But I could do this in like 5 minutes in WebForms!”
Sure, that might be true. In fact, your organization might not be suited for MVC development and this might be the right time for you to realize that. However, if you’re like me then you know that while the ramp up time might be a little rocky, it’s going to benefit you in the long run. So you explain the differences one more time and kindly ask them to just “give it a shot.”
Where’d my magic go? (Again)
“OK, so then how would I access my <some control ID> control?”
Even though you’ve explained it quite a few times by now, you’re bound to be asked again. In fact, don’t be too surprised if this continues to happen for quite some time.
As with the adoption of anything, you need a roadmap. You need clear goals and a vision to follow. The road is rocky at first and you’re going to need that vision to keep you moving.
Organizational Adoption
The damage has moved far past just affecting developers. I think an interesting shift in management’s understanding of .NET has happened in the past year or two. As management gets more technically savvy and buzzwords come and go, it’s more important than ever that management understands the goals of the roadmap you’ve set out. If you’re about to pitch using a new development approach that requires intense training and ramp up time then you’d be better be prepared for battle.
Sounds simple…right?
Let’s take a look at an application that is ideal for WebForms development. We need an application for internal-use only that will take in some input through a couple of data entry screens, run some basic calculations, and display the data in some sort of table. Sounds simple, right? It sure is. It’s so simple that I can write the steps out as follows:
- Figure out what data needs to be entered and throw together a database
- Create some pages and drag over some textboxes
- Wire up the code and give it a test run
- Drag over a grid view and wire it up
That’s all there is to it. There was no real need for design, no complex requirements, or any real thought needed to make this work. You’re happy because it took you about an hour and management is happy is also because it took you about an hour. There’s no need to discuss the details on what’s actually happening under the hood because it gets the job done and does it quite well.
Can’t you just drag and drop something?
We can create simple applications very quickly and effectively. This is where we have been for a long time and management has caught on to that. They’ve undoubtedly heard the term “control” get thrown around on more than one occasion and probably understood it to mean something quite different than what it really is. You see, WebForms does such a damn good job at simplifying things that you can’t blame them for thinking that a control is more powerful than it really is. Just think about the wide variety of controls that we have at our finger tips:
- Simple textboxes
- Login controls
- Grid controls
- Reporting controls
- etc.
What’s my point?
We’ve created it all: the good, the bad, and the ugly. We’ve built application after application and have done our best to incorporate testing as part of our daily routine but it hasn’t been easy. We’ve developed frameworks to help us test faster, but our budgets haven’t been fond of creating and/or maintaining those tests. ASP.NET MVC provides a brand new way of approaching development. We can finally incorporate Test Driven Development at the presentation-logic level and begin giving a higher level of transparency into the stability of our applications. It’s pretty clear why a lot of us are excited about this.
The pushback that we will be experiencing will come from two levels: developers and management. You will be dealing with real issues when developers pushback if they’re responding the way that I’ve mentioned here. MVC is so different than the world that WebForms created so it’s important to understand the sociological aspect of this situation. Management might not want to invest in testing, but I think it’s pretty easy to combat that one. It’s just important to think about it before making your pitch.
1 Comment
.
