Longing to know

Earlier this week, an article about technology choices was floating around the office: Choose Boring Technology

The premise of the article focused on technology choices and explained why sticking to tried and true technologies has merit. In my own experience, and in the same week, I find this article to be very relevant and had my own correlating experience.

As I discussed in another blog post on SSO/OAuth, I found myself needing a simple mechanism to manage basic SQL table structures (whitelists, clients, tokens, etc).  My first impulse was to design this as a SPA section within the application’s admin area. However, using a SPA framework for basic CRUD operations can be overkill.  It can actually be tedious and time consuming. If the main goal is to just “get stuff done” rather than focusing on UX, why spend countless hours on using newer methods/technologies at that particular juncture?

This is where “boredom” set in and reaching back into the Visual Studio’s MVC scaffolding tools made a big difference.

I find that ASP.NET MVC and the Visual Studio integrate is oft overlooked now a days because it’s no longer the “new hotness.” I’m guilty of this, as I mentioned above, and it can be an unfortunate side-effect of personal biases and goals/desires.

However, Microsoft’s tools, literally, made doing what I wanted take 5-10 minutes rather than the better part of a day (or two). The funny thing, though, is that while this choice would be considered “boring,” in the context of the referenced article, these are not old technologies, per se. We’re already up to ASP.NET MVC5 (and soon MVC6). I’ve long used ASP.NET MVC since v1.0 and understand it fully and watched it evolved and add new features. Sure, it’s not exciting any more, but it works quite well. Its use and patterns are vetted out to the extent that Visual Studio can scaffold views/controllers for you. And, unlike most code generators, the code is understandable and maintainable.

In my use case, I created a single Entity Framework (database first) context and a few models. After setting up my Area for holding the Admin section of my application, this is where taking advantage of the View/Controller scaffolding for all of my CRUD operations.

After we select to add an MVC Controller with Entity Framework context, we choose our Model and Context:

From there, the scaffolding produces our Controller and all of the CRUD views.

With these things in place (and the proper routing), I have very quick access to start editing the content in the SQL Server tables. Looking at the code, if you’re used to a typical Repository pattern, yes, it looks rather boiler-plate and somewhat boring.

The generated code is functional and understandable, and I was able to utilize it and move on to more important tasks.  That’s a key take-away for me in regards to technology choices and keeping things “boring.”