This past August, we made a huge shift in our server-side programming tools. Out were .NET web forms and in was ASP.NET MVC. Out were stored procedures and in was LINQ. Out was Anthem (a now unsupported library of .NET classes that added Ajax-y features to .NET) and in was jQuery. I’d become accustomed to everything good and excepting of everything bad about the old tools. But, change was necessary. We’d heard too much about what all the kids were doing.
It’s a bit dizzying to turn your workflow completely upside-down. But, a few days into it, things already started feeling really good. The decision felt right. MVC, as it always does in any programming language (see Cairngorm), at first feels a bit like your running in circles. But, once you finally wrap your head around the fact that URLs are routes, and not calling any pages at all, things start getting crystal clear. And, the nice conventions behind Controller names, default routes, and passing form variables from Views to Controllers rids any feeling that you’re doing too much setup (a typical feeling when you start MVC). LINQ literally feels like backwards SQL, but once you get it, you get it. And once you look past the dollar-signs, jQuery is a really easy syntax to grasp.
However, there’s one overwhelming feeling I have when I’m immersed in the .NET MVC/LINQ/jQuery triumverate. In their own unique ways, each is conducive to caring about the fine-tuning details later. Here’s how each set of languages really let you care about important things late in the game.
.NET MVC lets you care about workflow later
Separating UI from actions has it’s real benefit when workflows have to change. We recently built a tool for a client to moderate messages submitted by thousands of users. Our first build followed the conventional listing/detail format. Search for messages, get a list, click into each one to view detail info, and then decide to accept or reject it. Doing this a few hundred times wasn’t gonna cut it. So, we moved the moderation portion into the listing page. Because the UI is completely separated from the actions, you really just need to move the buttons.
In traditional web form world, we’d probably would have to move a bunch code-shifting, code-behind changes, and managing post back states – annoying grunt work that I’d fully accepted with web forms. MVC let us change the workflow of our application late in the game.
LINQ lets you care about filtering, sorting, and performance later
LINQ-to-SQL’s DataLoadOptions let you care about optimizing performance later. LINQ-to-Object lets you decide, at the last instant, if you want to do more intricate sorting and filtering. I can pull a category’s related subjects, decide to filter only the subjects that start with “A” and sort them alphabetically, on the View level, as opposed to caring about it at the stored procedure or even the Controller level.
Whether or not that’s a best practice is up for debate – but the option is there and there aren’t severe repercussions unless we’re mining a huge number of records.
JQuery lets you care about polishing your UI later
You can care about more sophisticated components or polished effects without worrying about rewriting or infiltrating your HTML.
The .NET MVC/LINQ/jQuery mix has been a great success for us so far. It let’s us not sweat the details until late in the game with minimal consequences.. It lets us build more and plan less.