I like using .NET MVC and have used it quite a bit in the past. I have also built SPA's using AngularJS with no page loads other than the initial one. I think I want to use a blend of the two in many cases. Set up the application initially using .NET MVC and set up routing server side. Then set up each page as a mini-SPA. These pages can be quite complex with a lot of client side functionality.

My confusion comes in how to handle the model-view binding using both .NET MVC and the AngularJS scope. Do I avoid the use of razor Html helpers? The Html helpers create the markup behind the scene so it could get messy trying to add angularjs tags using the helpers. So how to add ng-model for example to @Html.TextBoxFor(x => x.Name). Also ng-repeat wouldn't work because I'm not loading my model into the scope, right? I'd still want to use a c# foreach loop?

Where do I draw the lines of separation? Has anyone gotten .NET MVC and AngularJS to play nicely together and what are your architectural suggestions to do so?


5 Answers 5


You can certainly use any mix of client-side rendering and server-side rendering, but I would recommend against trying to mix ASP.NET MVC helpers with AngularJS directives. It might seem like a good idea at first because you're already used to using those helpers and you don't have to write "raw html", but they defeat the some of the purpose of what client-side applications try to achieve: separation of concerns, responsiveness, data-binding, and testability.

There's definitely a place for making mini-SPAs within a larger, traditional web-application, especially if you're converting a legacy application or if parts of the larger application don't need a SPA or are best served without it. But if you're going to render a given page - or part of page - on the client, then buy in completely and let AngularJS do what it knows how to do.

So let's say you have a Products model (some enumerable list of ) and you want to render that on the page in a list. You have three options I can think of:

  1. Use a razor @ForEach and render it server-side, but accept that your client-side AngularJS application won't know about this list and won't bind it to its model
  2. Wait until the page loads and AngularJS bootstraps, then make an API call to your MVC server-side application for some JSON data and stick it in the model. Use ng-repeat to render the list.
  3. Use razor to serialize the Products model on the server into some JSON string and embed that in the AngularJS controller you send back. Use ng-repeat to render the list and take advantage of client-side data-binding.

The last option is ugly. I can't think of a really good reason for it, unless you need client-side data-binding and you have to pay for each API call.

The first would be good if you don't need any data-binding on the client (it's a read-only list) or you need SEO.

The second is the way I would do it in most scenarios. You've decided to use AngularJS for a reason - let it do its job.

Don't use MVC helpers just because they're there. AngularJS provides its own directives that do much the same stuff. And if you need more, write your own. Part of using a client-side framework is buying in to the philosophy: the server is responsible for server-y stuff like authentication, server validation, and providing data through an API, and the client is responsible for being a front-end application. Keep your concerns separate.

None of this means you can't use ASP.NET MVC for routing, authentication, or the overall structure of your app. All that surrounds your AngularJS apps. Once you're inside a mini-SPA, though, do it the SPA way.

This is philosophy I've used when integrating ASP.NET MVC with AngularJS. The server-side MVC is responsible solely for rendering the initial page, and then providing a semi-RESTful API after that. It uses ASP.NET MVC to route URLs, authenticate, and other goodies. But there's almost no razor and definitely no HTML helpers.


A bit of an outsider comment/answer, I'm not a .NET MVC programmer but have done a lot of PHP, Java, and AS3 programming and relatively recently switched to AngularJS as well.

My general feeling is that the back end should just be RESTful and shouldn't touch the front-end really and the front-end should only depend on the back end for data. There are some exceptions for when it'd be better to create views server side (perhaps for consistent export for example or when caching of views will help significantly).

The advantage of the clear line of separation is allowing your teams to work independently or if you're a one man shop to allow you to focus on one task/problem at a time (can debug the back end separately from the front-end). Furthermore if your project expands and the clients are needing a native application solution you can still re-use your RESTful (REST isn't purely necessary but seems the way to go) back end and just re-write the front end.

  • I do like using MVC for my routing and really separating each page into it's own application by using the server side posting/routing. In this case I would have a Product MVC controller for example that loads the Product page (but has zero functionality) and I would still need a Product Rest controller that handles returning/loading the data. I've done an application this way but wondered if it was the right approach. Commented Mar 21, 2014 at 20:09
  • In SPA applications, ASP.NET MVC would typically provide HTML to the browser that serves as "scaffolding" which the Javascript framework can fill with data. So the server still has a UI role to provide. Commented Mar 21, 2014 at 20:14
  • I don't understand why you would want to tie the server side code to the view though, doesn't this make it more difficult if you try to re-write the front-end using technology like Objective-C or Android Java? I generally just run Apache web server since I'm using PHP and MySQL it all plays nice together and is relatively easy to configure. I use Slim PHP framework to make the server side routing easy so I can make a nice REST interface and still use OOP features of PHP for making DAOs for the database. Commented Mar 21, 2014 at 20:16
  • Because .NET MVC provides a lot of functionality out of the box. I can secure views by ASP.NET user roles very easily. I can have working authentication/registration. I have a very clean separation of each SPA or Page. Commented Mar 21, 2014 at 20:19
  • @RobertHarvey your comment about using MVC to provide the HTML scaffolding and then use JS (angular) to fill it will data makes sense to me. Just wondered if this is typical use. Commented Mar 21, 2014 at 20:22

I am building an app that is a combination of MVC on the server and AngularJS on the client.

On the server:

I found the easiest thing to do was to build a bunch of RESTful web api's to provide data services to the client. I also perform validation on the server to make sure that no one cheats (sending data using a client other than the web page). I also assemble the web page (though a controller and minimal view) to load all of the libraries it needs. Since I am building the web page with almost no changes from the view to the final HTML, I should be able to replace AngularJS with something else.

On the client:

On the client, I used AngularJS to handle everything from calling the web api's to local validation. It gives the user the "immediate" response that is being pushed by the latest push on the web. You can make your page dynamic or relatively static. By using an architecture that is using a separation of concerns, I can replace the back end with anything that supports a RESTful api.


We built an app that is a combination of AngularJS and MVC

The best practices say while using both MVC and angularJS, we should use MVC web api at server side to get data from server And at client side we should use Angularjs framework for binding JSON data with html controls.


Surely... if you have a SPA that describes the page and only requires data provided to it, then you need a RESTful server that fetches and returns the required data. Nothing more.

If you're trying to mix the two, then I think you might be making things very complicated. Sure using MVC to generate the initial pages is a decent idea, but once done - you still want the AngularJS calls to be making REST requests for data. Combining the two seems easiest when you keep the 2 technologies separate.

Not the answer you're looking for? Browse other questions tagged or ask your own question.