Modular Way To Develop AngularJS Single Page Application

Introduction

In this article, we will discuss about a modular way to develop AngularJS single page applications for better maintenance. The example code demonstrates sign up and login functionality and you can improvise it as per your need. It is available here.

Background

You should have knowledge of the following technologies for understanding the code.

• AngularJS 1.5  - used for the business logic of the application.
• Asp..NET MVC 5 - used as a wrapper around Angular code.
• TypeScript 2.0  - used to implement the OOP easily in Angular code.
• Asp.net Web Api 2 & Oauth  - used for server side business logic of the application.
• Mongodb  - used to store data. (optional)
• Repository pattern  - used for decoupling a data access layer from the application. (optional)
• MEF (optional)

Take Away from this article

• Developing AngularJS as Mini SPA
• Use of AntiforgeryToken and Token based authentication and authorization for Web API 2
• Use of OOPS in AngularJS using TypeScript.
• Use of ASP.NET MVC for reducing the complexity of a big application.
• Developing the SPA in modular style.

Drawbacks of traditional SPA approach

• Difficult to maintain a big application since everything gets added literally in a single page/file.
• Single Routing file becomes bigger and difficult to maintain.
• Single Home page stores all application references like  CSS and JS files.
• Understanding and maintaining the existing application becomes very difficult; changes can lead to more bugs.
• Cannot use approach like ASP.NET MVC AREA where we can separate functionality and the code.
• Mixing Angular code and ASP.NET MVC is not a good idea. (This approach is very inflexible and sometimes writing unit test cases for Angular code becomes quite tricky).
• Cannot take advantage of OOPS.

Advantages of my approach

• Instead of developing a big SPA, break the functionality into multiple Mini SPAs.
• Using TypeScript for implementing OOPs in AngularJS code.
• Separate routing file for each mini SPA.
• Separate ng-app module for each mini SPA and the module can be reused in the other modules.
• Separate homepage for each mini SPA, which can hold only required reference files.
• A module can be used as an app module/root module in one mini SPA as well as can be used as a normal module in another mini SPA.
  
• Using ASP.NET MVC as a wrapper just to load required references and to bundle the reference files and for mini SPA’s homepages.
  
• Basic authentication can be done in UI project since ASP.NET MVC is wrapper and each feature (mini SPA) can be guarded.

Suppose, we are developing a dating site which has the following features.

• Welcome page
• SignUp
• Login
• External login
• Profile Search
• Advance Search
• Individual Profile
• Payment by card/paypal

Instead of considering these features as one application, we will separate the above functionality into three mini SPAs, as shown below.

1. HomeSpa 
   
   
1. Welcome page
2. SignUp
3. Login
4. External login
   
   
2. SearchProfileSpa 
   
   
1. Profile search
2. Advanced Search
3. Individual profile
   
   
3. PaymentSpa 
   
   
1. Payment by card
2. Payment by paypal

Only a few functionalities have been implemented in the sample code that is available on GitHub here.

Sample Code Explanation

The sample code solution has the following layers.

1. UI folder - Sample.MVC.Angular.UI - It is AngularJS project wrapped in ASP.NET MVC.
   
2. ApplicationServices folder - DatingSite.WebApi4 - It is Web API layer which gets called in AngularJS code.
   
3. DomainServices folder - Contains the projects related business layer which gets called in Web API projects.
   
4. MongoDbAccess - Contains the projects related data access layer which gets called in Sample.DomainServices project.

You can focus only on the UI folder - Sample.MVC.Angular.UI project. The underlying layers follow the repository pattern and you can replace these layers by your business and data access layers easily.

The below image shows Mini SPA folder structure in the UI project.



For each mini SPA, we have an MVC Controller and a View page which will play a role of container page, just like ASP.NET MVC area and will hold all reference files of the related Mini SPA.

All Angular code goes under the Mini SPA folder and a sub folder for each mini SPA.

All mini SPAs are Angular modules and can be reused just in another module.

ModuleInitiator.js



This module creates or loads a module with required dependencies automatically when MiniSpas.ModuleInitiator.GetModule() method gets called.

_Layout.cshtml



The file contains references of files being used by all mini SPAs.

And, specific references, required only for a particular mini SPA, will be in the index.cshtml page which gets called by MVC Controller when mini SPA is requested.



Mini SPA structure

Each Mini SPA has each routing and module creation code. The code has two layers – Controller and Services, as shown below.



That’s it

You need to go through the code for better understanding. Let me know what you think of the approach/application architecture.