Welcome to the final part of this review of the Pluralsight course Build Your Own Application Framework with ASP.NET MVC 5 by Matt Honeycutt.

Matt is a software architect specializing in ASP.NET MVC web applications. He has over a decade of experience creating web applications. As an avid practitioner of Test-Driven Development, he has created both the SpecsFor and SpecsFor.Mvc frameworks.

Matt has served as the lead developer on numerous multi-million dollar software projects and enjoys finding elegant solutions to difficult problems.

On Github, he has published the Heroic Framework and the Fail Tracker web app. These projects feature much of the code and techniques that are covered in this course.

Also in this series:

Part 1 -What is an Application Framework?
Part 2 – The Power of an Inversion of Control Container
Part 3 – Optimize Your Controller Layer
Part 4 – Optimize Your View Layer
Part 5 – Optimize Your JavaScript

Our Goals in this final module are to:

• Standardize Client/Server Communication
• Provide Consistency between Client and Server Code
• Leverage Conventions and String-Typing
• Drastically Reduce Boilerplate Markup

Optimize Your JavaScript

Demo: Fail Tracker Review

A couple of new libraries have been added to the project: Angular.js and Underscore.js

We also see failTrackerApp.js has been added and there’s a controllers folder inside the scripts folder.

We see that all of the Angular code is mixed in with the server side View.cshtml code. Matt says there’s a lot of code in there that he doesn’t like.

The model is being manually converted into a JSON object, which is then passed off to our controller.

There’s a lot of markup and a lot of noise in there.

Standardizing Client/Server Communication

Matt says the default ASP.NET MVC Model Binder works well for receiving JSON in most scenarios.

The built-in JsonResult class leaves a lot to be desired though.

C# is Pascal-Cased according to Microsoft recommended practices, whereas JavaScript is camel cased. It is best to use the generally accepted styles for whatever language we work in.

We want to have our application framework translate our JSON to meet this requirement.

We should also have a consistent way to indicate when something has gone wrong. We should be sending back the appropriate status codes, and never return HTTP 200 when we have an error.

Demo: Standardizing Client/Server Communication

We creating a StandardJsonResult class which inherits from JsonResult.

See FailTracker’s StandardJsonResult

Use of the standard JsonResult is discouraged by an [Obsolete] annotation for a compile time warning. If developers use this anyway then the super controller throws an InvalidOperationException when it is used.

So what do we use instead? We create superior alternatives, and by the end of this demo, we are using JsonSuccess for HTTP 200 successful responses, and JsonError for HTTP 400 messages, which are sent with any relevant error messages.

You may want to be careful with the error messages that are sent down to the client. You probably don’t want to give your users access to all of your stack traces. This is all overridable though.

Encapsulating Site Services

Our ASP.NET MVC application uses Bootstrap for notifications.

However our Angular JS code only displays the ugly browser default alerts.

So we have an inconsistent user experience.

Demo: Status Messages

The code we write here is independent of Angular JS so that we can use it with any client-side JavaScript code.

We start by creating bootstrapAlerts.js and Matt explains all of this code here.

Then we add this file to our JavaScript bundle by updating BundleConfig.cs

If you are new to bundling and minification in ASP.NET MVC, check out Travis Gosselin’s course.

In this lesson, Matt also adds a partial view to _Layout.cshtml and talks through the _Alerts shared view.

We see alerts.js which creates a new AngularJS service. Finally we update our controllers to use this alerts service.

Client-Side Error Handling

We want users to see helpful error messages if something goes wrong with our script.

Demo: Client-Side Error Handling

First, Matt demonstrates how badly the application currently handles errors: we are just greeted with a blank page.

Users will have no idea what went wrong. Developers though, know to open the console to view the errors.

Next, we add a global error handler in failtrackerApp.js

We see that this message gets initially displays as a standard browser alert, because the error happens before our bootstrap alert engine has loaded. We see the bootstrap alerts appear next.

Than we see that nothing happens when the user clicks on the edit button. This is because Angular JS caught and logged the error for us.

We add a new script exceptionOverride.js which is an Angular JS service that logs the error and also displays it.

Accessing View Models with JavaScript

Matt says moving data between C# and JavaScript is a BORING uninteresting concern.

To remove the tedium, we’ll create a custom HtmlHelper that will simplify this process for us.

Demo: Accessing View Models with JavaScript

In this lesson we see how to convert a view model into it’s JSON equivalent.

The code described here is the Json method in the FailTracker JavaScriptHelper.

Conventional UI with AngularJS

Matt says that although we eliminated the repetitive markup in our view in the last module, due to the use of Angular JS it is back with a vengeance!

Demo: Conventional UI with AngularJS

This lesson focuses on simplifying the lengthy edit markup with ASP.NET MVC’s editor template system.

We start by adding the AngularEditorForModel, AngulatBindingForModel and CamelCaseIdForModel methods into our JavaScriptHelper.

We create an Angular subdirectory inside Views/Shared/EditorTemplates with Object.cshtml

We also create AngularTemplateHelper, which contains HtmlHelpers and includes a Template Map which is similar to the one used in the ASP.NET MVC Templating system.

Matt explains that the Microsoft code isn’t exposed for our use, so we must replicate it here.

Matt also walks through the GetTemplateForProperty method, and runs up the application.

To fix a few problems, we create copies of our existing partial views into our Angular folder and make a few edits.

Matt’s Closing Thoughts

Matt ends the course with a reminder that our application framework should be tailored to our own pain points. Every application has some sort of framework, but they need to be nurtured, otherwise they may evolve in a haphazard way.

Verdict

Beginner friendly courses, books, and online articles on web development are commonplace, but comprehensive information on how to architect a real world application is much rarer.

This course is very valuable because it raises many architectural issues that you will need to deal with, and presents well thought out solutions that will not just make your life as a developer easier, it is likely to lead to higher quality applications and happier end users.

Other resources that I have found complement this course well are Alex Wolf’s MVC Request Life Cycle, and Eric Elliott’s book Programming JavaScript Applications.

Alex Wolf also has a course called Improving Your MVC App with 10 extension points which may be useful.