While the Razor syntax provided in the View layer for .NET apps is very powerful, it isn’t always as flexible as you need, and won’t always provide you with friendly markup on the front end. At the same time, there may be instances where you’d like to decouple your front end from the back end, and in those cases you most likely won’t want to use Razor at all in favor of plain HTML.
While working for New Signature, I recently produced a dashboard for a client, powered by a .NET API using the Web API framework, and AngularJS on the front end. We created lots of charts and graphs to view various information: exactly what you’d expect in a dashboard. Those chart widgets were developed using the equally fantastic D3JS library. If you’re looking to create custom charts, maps, or any other kind of visualization, you’ll want to check D3 out as well.
Yet I digress.
The views were written as
cshtml documents, that way I can incorporate the Razor syntax where needed. For example, rather than let the front end handle authentication, we left that to .NET. We were redeveloping a previously built application, and rather than write functionality to handle authentication, we left it with .NET and Razor. The AngularJS view layer is of course plain HTML, and that’s the most simple and direct way to work with the browser. Yet as I’ve demonstrated, there are sometimes cases where you need Razor, and if you can allow yourself that flexibility you should take it.
You certainly don’t need to keep Razor for anything though, and totally decoupling the front end leads to some unintended benefits. For example, a strictly HTML / JS front end can be hosted anywhere. It need not live in the .NET project at all. In this situation, the .NET app is strictly an API layer. Once you’re in this regime, it will lead you to even more possibilities. A client may want an iOS app or Windows Store app. If you have an API layer, you can create an HTML / JS app with AngularJS, then package it with PhoneGap (a.k.a. Cordova). This will result in giving you a fully native app that’s eligible to be sold in its respective marketplace. That’s clearly better than hiring specialized teams of native app devs.
On the front end, routing between pages is handled by AngularJS. On the .NET end, pages are served via the standard MVC architecture. Like any other .NET app, you’ll have a single layout. The layout needs an ng-view container where AngularJS will insert your view. If you’re maintaining Razor in your view layer, you’ll need to include the @RenderBody directive inside your ng-view container.
We left all our views inside the Views directory, just like any other .NET application. You’ll need to create a dummy controller whose only purpose is to serve up your AngularJS views. The controller name doesn’t really matter, so name it something like FrontEnd. Or, you can do what we did and just serve the views out of your Home controller:
You’ll see we’re returning a PartialView. In the .NET framework, this just means to return the contents of a view partial without wrapping it in the layout – exactly what we want. Now, in your AngularJS app, you can setup a route like this:
The actual view should be placed in the same directory that .NET expects it to be located. In this example, that is
Now that we’ve made it this far, I wanted to share some strategies I used during the development process.
Here are some resources to learn more about using .NET with AngularJS and Cordova.
- A template extension for a SPA in AngularJS for .NET
- You can use Grunt as you would in any other application development, but Mike O’Brien shows an advanced implementation integrating Nuget, testing, and deployment.
- Daniel Zen on using AngularJS & Cordova to build native apps