Monday, April 25, 2011

While my keyboard gently weeps

As I wait for the ability to offer a bounty on my route error/500/404 problem on Stack Overflow, I figured I might as well write a letter to Microsoft about what I feel they can do better for newbies, like myself, attempting to jump into using their stack for web development.

1. Don't assume anything.  This has to be the biggest area of frustration for me.  There seems to be an underlying assumption that a lot of incoming MVC devs are former web forms devs.  Similarly, there's an assumption that we're comfortable using Visual Studio.  From my personal experience, I do know a little bit of web forms, mostly how horrible the Page object's life cycle is.  I also know what Web.config is used for in an abstract sense, but am certainly not comfortable mucking around in there.  I'm barely competent with VS, having learned the hard way when to build/rebuild a project so it will work right when debugging.  I'm sure others aren't even at that level when they start down this rabbit hole.

2. Ignored or glossed-over info.  This really should be considered 1A.  Again, there's an assumption being made that people are familiar with ASP.NET and are mostly just migrating to MVC and/or EF4.  Look at the model binding validation fiasco I went through earlier.  Even better, look at the route problem I'm currently facing. 

I own what could likely be considered the tome on MVC 2 - Steven Sanderson's Pro ASP.NET MVC 2 Framework.  It is a great book which explains every part of the framework.  In fact, there's an excellent chapter (Chapter 8) which describes, in detail, MVC's routing mechanism.  What it doesn't explain is how to handle malformed routes.  Web.config's customErrors tag is mentioned just once, in passing, on page 612 in Chapter 17, which is dedicated to deploying MVC 2 projects.  That's it.  No description about what customErrors is, nothing about bad routes at all, no hints on making route errors fit into the rest of the routing system, or anything else.  I can't fault the book for not addressing my EF4 issue, as it works with LINQ to SQL instead, but shouldn't malformed routes at least be addressed briefly?

I'm not trying to crap on the book or its author.  I've found, that aside from the bad route issue, it's a great book, and recommend it to anyone looking to join in the MVC 'fun'.  What I'm trying to illustrate is a pattern.  If one of the framework's best books neglects to mention something that is fairly important like handling bad routes, then how are we beginners supposed to know what the hell to do?  It's certainly not addressed (at least, not addressed well) in the demoware, which is where most newbies start.

3. Smaller gripe: where's the at-a-glance info?  I want to know what kind of debugging errors I can step through compared to those I can't.  I want to know what those step-through errors would mean in a live, release environment.  I want to see the differences between Entity Framework 4.0 vs. 4.1, and how the common patterns have changed.  I'm sure this info exists somewhere, but its spread throughout the ether, buried in articles and blog posts.

So, now that I've vented a bit, I have some constructive suggestions on how to make the newbie experience better.

1. Don't assume we come from web forms country.  My background is in PHP.  I've used a grand total of 1 MVC framework in that environment - Kohana 2.something - and it doesn't exhibit any of the Microsoft idiosyncrasies like Web.config.  My IDE of choice back then was Notepad++.  A lot of other wannabe MVC devs comes from similar, or even NO web development backgrounds.  Keep this in mind.  I'm sure a lot of us are willing to skip over the bare-bones basic info we already know if it means you're actually covering all the basics.  I'd rather be inundated with the "No shit, can we move on?" stuff than not.

2. With that said, maybe create a newbie starter pack filled with the info we need to know before diving into MVC as a whole.  Topics could include basic Visual Studio usage (ex: knowing which errors can be stepped through, those that can't, and the differences between them), the basics of ASP.NET (things that are shared between web forms and MVC, like Web.config), and basic C# (ex: LINQ, lambdas, etc.).  If there's a minimum requirement or some prerequisite we need to know before getting into MVC for real, as there seems to be, then why not provide it in a centralized manner?

3. Be thorough.  Books, at least, shouldn't gloss over anything.  I'd rather have the option to dig through the innards of the framework than not.  Again, more information, not less.

In closing, I like the idea behind MVC, and I'm trying to buy, literally, into the platform.  I'd like it if it didn't seem like Microsoft and supporters of the framework made it easier for me to do so.  I'm not looking for anyone to hold my hand or write my code.  I just want the tools in order to do it on my own.

No comments:

Post a Comment