Last weekend, I attended the Lansing “Day of Dot Net”. I really enjoy events like that because I get to see what are the latest trends in programming and learn how they work. It helps me make informed decisions about whether a new technology would be appropriate for my environment and our projects.
I sat-in on a good session about T4. After the presenter was done, he mentioned other topics and talked about how he didn’t “get” MVC at first, then one day, it just clicked in his head and now he loves it. That piqued my curiosity, so I attended the afternoon session on ASP.NET MVC.
The speaker for ASP.NET MVC was from a well-respected consulting company that I admire very much. He started his presentation by saying that ASP.NET forms (1.0-2.0) was really complicated and the API was huge and that you really needed tons of special knowledge to understand how the viewstate in ASP.NET 2.0 functioned. I was like: Huh? Because ASP.NET forms is a total no-brainer and I used it for years before I had the slightest clue about the viewstate. Plus, I mostly use 1% of the huge API unless I want to apply some of my ninja skills. Even then, I only dig into 50% of it. The other 50% is only there for flexibility, just in case you want to use it. So, when he said that ASP.NET forms was really complex and ASP.NET MVC was WAAAAAAAY simpler, I was stoked. I had no idea that web programming could be any simpler than it already was. So bring it on!
Then he did his demo. He showed a simple web site with 3 pages that tied into a database with one table (3 columns: ID, Name, Balance). I’m thinking: In ASP.NET, that would be drag-drop for 1 minute and ten lines of code…done! …his demo was no less than 12 files. Much like other MVC demos that I have seen up to now, he was required to produce a complicated solution for a simple problem. Ugh.
The presenter briefly touched on “Separation of Concerns” (SoC) and said it was really important. Other parts of his demo showed that with ASP.NET MVC:
- Fields are not automatically refilled for you, because there is no viewstate. So all the pages are stateless. Which means you are responsible for coming up with a strategy for maintaining state. MVC doesn’t handle that or contain any tools to make that easy for you.
- <asp:TextBox> and <asp:DataGrid> and all the other asp controls are GONE. You can’t use them with ASP.NET MVC. You have to do this <input type=”textbox” value=”<%= Person.FirstName %>” />. Which means you can’t have a graphics dude touch the UI once you’ve coded it. No more WYSIWIG editing.
- Since MVC is supposed to be stateless, the event model was handled in the URL, which looked sweet, but creeped-me-out when I thought about the security ramifications. I’m sure there is a way to secure MVC, but like other MVC stuff, it probably wasn’t built-in or obvious. You had to a lot of thinking and design something yourself.
There were a few cool things about ASP.NET MVC:
- URLs showed the actions. It reminded me a little of fusebox. It would probably be easier to test.
- QueryString arguments were automatically passed in as parameters to your event handlers. However, it looked pretty fragile because if you change your design (or rename something), the names wouldn’t line up and it would error-out on you.
- You could add models and controllers by right-clicking files and it had options for generating files and code, etc. Pretty handy and a big time saver for sure. Unless it doesn’t generate it the way you wanted it.
In the end, the presenter said ASP.NET MVC was super easy and every rookie should only learn it instead of original ASP.NET because MVC was way easier. However, he clearly demonstrated that the exact OPPOSITE was true.
In reality ASP.NET MVC:
- Has a (somewhat) steep learning curve. So it is not for rookies. It doesn’t make simple things any easier until you really understand it very well. Rookies will hate your code and they will struggle to work with your code (without breaking it or doing it wrong).
- You are responsible for planning everything. If you are not good at gathering requirements or planning-out your project before you get started, you will pay.
- If you are on a team of experienced individuals, MVC will be super-cool and your team will rock well together. If anyone on your team is not experienced, they will struggle and not “get it” and that will start to bother you after a while.
- MVC and SoC makes it easier to do automated unit testing of your stuff. If you are already into automated unit testing or trying to get into it, MVC will seem pretty sweet to you. If you are not into automated unit testing, you won’t be enjoying the biggest benefit of MVC. In fact, it is likely that you probably aren’t doing several other things that will help you benefit from MVC. So, MVC will probably be a big pain in the wazoo instead of the neatest thing since Kraft singles.
In the last 5 years, I have mostly worked with people who would have REALLY struggled with MVC. My current project, is to take a series of projects (approx 50), with no source-code and get them to stop breaking on a daily basis, so we can actually make some progress around here. A third of those projects were done in some form of MVC. So, each project consists of 10 – 100 files. Keep in mind, these aren’t huge programs, they are things like: “Contact list” or “User synch”. Each could be written in under 1000 lines of code. Instead it seems like each one is totally obfuscated. The pain is indescribable.
Maybe the previous developer had all sorts of automated unit tests written and was building a SOA or ESB and that’s why everything is so huge and spread-out. However, he didn’t believe in VSS (Visual Source Safe or equiv.), so when his hard drive crashed, all that was left was a complicated mess of DLLs that had to be decompiled. In this case, MVC has proved to be a great-big nightmare instead of the-coolest-thing-since-USB.
So, if you work at a place that has any rookies or sand-baggers, or if there is any chance that you might lose your dev tools, or someone might have to take over your work, it is okay to hate MVC. Don’t cave-in under peer-pressure or yield to the exaggerated reasoning of technical evangelists. Do the right thing for your employer!
Make sure your work is maintainable by the people who will have to maintain it. Otherwise, your super-slick raz-a-ma-tazz will become someone else’s nightmare. Don’t get me wrong, I love cool new stuff. I’m just saying: don’t be the guy who blindly jumps on every new bandwagon, regardless of where it takes you. Be a realist and do the ACTUAL right thing for your business, even if it doesn’t earn you any cool points.