ASP.NET MVC MPA (multiple page application) with AngularJS

data: 12 października, 2018
czas czytania: 9 min
autor: Maciej Pszczoliński

If you create your modern, brand-new page in a well-known ASP.NET MVC, sooner or later you will need an asynchronous code. The obvious choice is (or was?) a jQuery. The problem is that despite being a powerful library, jQuery requires quite a lot of coding to create even basic stuff. Our team needed a 2-way-binding, easy-to-use, well-documented substitution to jQuery. Finally – we have chosen AngularJS. However, in the .NET world the MVC is an MPA (multi-page application) but AngularJS is more into the SPA (single page application) approach. But first, let’s explain why we had to implement such an exotic solution. We were given a legacy code done in the MVC/spaghetti/jQuery/more-spaghetti/JS approach. The client’s requirement was to preserve the existing functionality, but we were given a free hand regarding refactoring. Rewriting stuff from scratch was quite risky so we decided to approach the problem piece by piece.

At the very beginning, we noticed the MVC limitations (one model per page, synchronous requests, same model for the response and request operations).

The solution, of course, was AJAX.

If AJAX then jQuery, right? Right, but not these days because you will probably end up with huge JS files, in which you will be manually accessing form fields (constantly keeping an eye on the selectors, IDS or CSS classes just for field identification, etc.). I grew up on AngularJS/knockout.js 2-way-binding, so I knew that this would solve a lot of problems. Additionally, we got a great mechanism (AngularJS directives) for creating reusable widgets/components.

Note: in our real application we use more technologies, like SCSS, gulp, etc. but provided examples will be simplified for the purpose of this article.

So… how to combine MVC and AngularJS? The answer is:

  • Give up (at least at the beginning) on the AngularJS routing
  • Consider each ASP.NET MVC page as a small and super-simple AngularJS SPA
  • (optional) Convert an MVC model into JSON so that AngularJS can understand it

Prerequisites

I assume you can install AngularJS yourself within your project. We used npm and gulp for that but you can use whatever technique you like.

Project structure

Here goes the example of a basic project structure:

  1. AngularJS files go here.
  2. For the demo purpose, models are located here but for a really big application it is better to create separate projects with Entities, DTOs, etc.
  3. Here go other JS scripts, which are NOT AngularJS ones.
  4. A standard MVC Views folder but for a large scale application you can consider using Areas.

Combining AngularJS scripts with razor file

So now let’s see the cshtml Razor file, for Cars:

    1. Standard ASP.NET MVC Model type declaration
    2. Here we render the AngularJS files required ONLY for this single view. The ngApp section placeholder is defined in _Layout.cshtml
    3. Here comes THE MAGIC. This line of code “converts” an MVC backend model into a JSON object understood by an AngularJS frontend (it will be consumed in the browser, not on the server side).

I have presented above the header part of a file and now it’s time for the “real” AngularJS markups (the continuation of the same file):

  1. Defining what the AngularJS controller is responsible for while handling this part of a frontend application (carsController is explained in detail in the following part of this article).
  2. “Angularish” forEach loop. Here we iterate items in our model. We know that our model is an array but you can easily imagine your models with a much more sophisticated structure.
  3. Simple access to the property of an item. Double mustache brackets tell AngularJS to render it in DOM.
  4. Accessing a nested object within the item.
  5. Accessing the JS length property on a nested array Wheels (Note: we assume that Wheels is never null in that case).
  6. Building URLs for MVC actions.

Basic HTML is covered but it won’t work without a controller.

  1. This is not crucial but I like using the vm (short for ViewModel) naming instead of a $scope.
  2. Example of a function that can be accessed from HTML.
  3. Calling initialization. I like such an approach to put all the initialization logic in a function (the function that is not exposed in the vm). Note how MvcModel is accessed. This is the MvcModel that we converted our model to.
  4. We assign our model to the model so it can be used in an HTML (cshtml) file. In this case, the body of the _init function is extremely simple but it may grow while the project is being developed.

Backend code that handles a razor page – Index (listing) action

Let’s see a little bit of the C# backend code.


As you can see – nothing here is different from the standard MVC approach.

  1. The action. Standard MVC stuff.
  2. In your real application, you will get required data from repository, service, or any other DAL.
  3. Super standard return of a razor view with an attached model.
  4. Mocked data.

The conclusion is that using AngularJS does NOT change the C# controller approach.

The idea of using RootUrl variable

In the above examples, you may notice the RootUrl. It is used because you can’t always use relative URLs starting with “/”, e.g. in the case your URL is like this http://localhost/APP_NAME/. If you use relative URL, the “APP_NAME” part will be missed and your app will stop working. Here is the solution (in _Layout.cshtml and app.js):

  1. Server-side rendering of a root URL and saving a global JS variable under a given name.
  2. Saving RootUrl in $rootScope so it can be used in every AngularJS controller.

So far so good. Next issue to be solved is error handling. Let’s start with ModelState errors. First, we will modify our cshtml model-to-json serialization so that it serializes both model and errors. The above code was based on the listing of all cars whereas the following example covers adding and editing car.

Razor file for “Add and Edit” actions

First, let’s create an AddEdit.cshtml file:

The AddEdit.cshtml file starts like this:

  1. We are using here another model which is only for adding and editing a certain entity. It will be explained in the following part of this article.
  2. This is the most important part of the errors (and operation) serialization model. It uses an extension method that serializes model and errors to a convenient representation.

Extending ModelState and ViewModel

First, let’s create a new Extensions folder in our solution:

Now, let’s analyse the extension methods:

  1. We return our custom class object which combines a model and possible errors. It is convenient to keep it this way.
  2. We simply copy the Model to the Model property of our custom class.
  3. Here comes a bit more magic – the actual ModelState error mapping.

  1. Convert errors to a dictionary.
  2. Take the errors of the keys with the number of errors different than zero. In other words – do not take empty errors.

There is one more trick to make it work. Since razor is not aware of these extensions methods, go to the Web.config file in the Views folder and add such a line:

  1. Adding extension namespace

Add and Edit controller actions

Having the above code prepared, let’s see how the CarsController.cs gained few new methods.

  1. For the Add action, return to the AddEdit view with an empty model (because we don’t need any predefined existing model).
  2. For the Edit action, return to the AddEdit view but the model should be predefined with the data of an already existing car.
  3. In a real application, you should get existing model data from DB and map it to a model type that is expected by the cshtml file.
  4. Add the POST action. It gets the model of an AddEditCarViewModel type and checks if it is valid.
  5. If not, it is returned (together with model errors) so we can correct the errors.
  6. In another case, if the model is valid, we perform some add/save operations on it, and we redirect it to the Index action, which is a list of all cars.

Let’s proceed to discuss an AddEditCarViewModel file as I have promised earlier.

  1. Id is nullable (Guid? notation) because we don’t need it for an adding operation (Id is set/determined on a server side). Because we aren’t able to avoid invalid model errors (due to missing Id), we set it as nullable.
  2. You can denote some properties as required, so validation will be performed automatically. Validation is a big issue and since it is not the scope of this article, it won’t be discussed in detail.

Getting back to Add and Edit razor file

Now we can see the AddEdit.cshtml:

  1. Client-side rendering of the action’s URL – either Add or Edit, depending on the model. If the model contains Id, we assume we are editing. If Id is empty, we assume we are adding.
  2. Validation summary directive. It is a custom directive and will be discussed later.
  3. Keep a current model Id in a hidden field.
  4. name properties of inputs have to match properties of AddEditCarViewModel.
  5. Custom submit button directive, which will be discussed later.

To make it work, we also need an AngularJS controller.

  1. Determine the mode for the angular controller. It is either Add or Edit so the Boolean value is sufficient.
  2. Keep object (car) model and errors in separate properties of vm. Please note how vm.validationErrors are passed to a validation-summary directive.

AngularJS Directives

One of the final things to be presented here is directives. They are reusable items and you can consider using them in the case you have repeated code in html. In our case, there are validation-summary and submit-buttons.

Since they are used in many places, let’s add it to the _Layout.cshtml.


Submit button – HTML:

Submit button – js:

HTML Validation summary:

JS Validation summary:

And finally, validation summary in action:

Conclusion

In this article, we have covered the basics of combining ASP.NET MVC with AngularJS. Sure thing, the discussed examples are simplified but the point of this article is to show just the code needed – no more, no less.

Newsletter IT leaks

Dzielimy się inspiracjami i nowinkami z branży IT. Szanujemy Twój czas - obiecujemy nie spamować i wysyłać wiadomości raz na dwa miesiące.

Subscribe to our newsletter

Administratorem Twoich danych osobowych jest Future Processing S.A. z siedzibą w Gliwicach. Twoje dane będziemy przetwarzać w celu przesyłania cyklicznego newslettera dot. branży IT. W każdej chwili możesz się wypisać lub edytować swoje dane. Więcej informacji znajdziesz w naszej polityce prywatności.

Subscribe to our newsletter

Administratorem Twoich danych osobowych jest Future Processing S.A. z siedzibą w Gliwicach. Twoje dane będziemy przetwarzać w celu przesyłania cyklicznego newslettera dot. branży IT. W każdej chwili możesz się wypisać lub edytować swoje dane. Więcej informacji znajdziesz w naszej polityce prywatności.