Intro to Full Stack Development

Table Of Contents
  1. MVC Architecture Reviewed
  2. Full Stack Architecture
  3. Angular Architecture

Back in Chapter 3, we looked at the ASP.Net Core MVC framework. Let’s take a minute and review the architecture of that framework.

MVC Architecture Reviewed

Figure 1. MVC (Model-View-Controller) Architecture

Looking at Figure 1 above, we can review the responsibilities of each MVC component layer and break down what happens in the MVC architecture for a User Request and Server Response.

MVC Layer Responsibilities

Model: Responsible for querying or updating the database. In the context of ASP.Net Core MVC, the Model represents all of the objects in our business domain. Objects are represented by C# POCOs (Plain Old CSharp Objects). Entity Framework Core is typically used to persist updates to the domain to a database.

Controller: Responsible for business logic and flow of control within the application. There should be no HTML within the controller.

View: Responsible for rendering the data in HTML format. There should be no business logic within a View.

Note: The fact that there should be no HTML in the controller or business logic in the view reinforces an important software engineering principle called: Separation of Concerns. Each layer or component has a separate responsibility. Later we’ll see how this structure allows us to create much cleaner code making coding, maintenance, and unit testing much easier.

MVC Request/Response sequence

  1. The user types in a URL address in their browser and sends the request.
  2. The Controller receives the request and uses values from a query string in the URL or fields from a form post to update or query entities in the model using a dbContext object which is also part of the model.
  3. The Model then either queries the Database or persists updates and creations of entities to the Database and sends the query results back to the Controller.
  4. The Controller sends the query results to the View and the View renders the data in HTML.

Full Stack Architecture

We’re going to take a fairly new spin on the architecture we have become so familiar with up to this point.

To begin with, we will still have an ASP.Net Core application for the backend. But instead of an ASP.Net Core MVC application we will be using an ASP.Net Core Web API application which is very similar. In fact, MVC and Web API applications are so closely related they used to be in the same namespace. Although, now they each live in their own namespaces.

Secondly, instead of rendering the HTML in an MVC View, the Web API controller will send back raw JSON data as a result.
And we will have a totally separate application for the front end. This will be an Angular application or SPA (Single Page Application). The Angular application will consume the JSON data sent back by the Web API Controller.

Figure 2. Full Stack Architecture

Web API Layer Responsibilities

Model: Responsible for querying or updating the database. In the context of ASP.Net Core MVC (or in this case Web API), the Model represents all of the objects in our business domain. Objects are represented by C# POCOs (Plain Old CSharp Objects). Entity Framework Core is typically used to persist updates to the domain to a database.

Controller: Responsible for business logic and flow of control within the application. There should be no HTML within the controller. In a Web API Application we are not dealing with HTML anyway so there is not much chance of breaking this convention.

JSON Response: The JSON Response is not really a layer or component. Just note that instead of the Web API Controller returning a ViewResult containing the HTML like in an MVC Controller, it will now just return data in JSON (JavaScript Object Notation) format.

Web API Request/Response sequence

  1. The user types in a URL address in their browser and sends the request.
  2. The Angular application receives the request and loads the appropriate component based on the URL.
  3. The Angular Component sends a Restful API request to the ASP.Net Core Web API application.
  4. The Web API Controller receives the request and uses values from a query string in the URL, HTTP parameters, or a JSON Object in the body of the request to update or query entities in the model using a dbContext object which is also part of the model.
  5. The Model then either queries the database or persists updates and creations of entities to the Database and sends the query results back to the Controller.
  6. The Controller sends the query results back to the Angular application in JSON format and the Angular application consumes and renders the JSON data in HTML format.
Note: dbContext above refers to the dbContext in Entity Framework Core. The dbContext is part of the Model and is how the controller communicates with the Database. Entity Framework Core is an ORM (Object Relational Mapper) that allows us to write database queries and updates using our C# objects as entities that map to the tables in the database rather then manually writing SQL Queries.

Angular Architecture

Before we move on let’s take a deeper look into the architecture of an Angular Application.

Angular itself actually uses the MVC software pattern a lot like ASP.Net Core MVC does.

Figure 3. Angular Architecture

So we’ve already noted that Angular itself uses the MVC software development pattern but we can see above in Figure 3 that the terminology is a little different.

A Component is a lot like a controller in ASP.Net Core MVC.

And a Template is basically like a View. This is where HTML is contained mixed in with Angular directives, JavaScript, and TypeScript.

Angular usually delegates the responsibility of querying and updating a database to a Rest Service in some sort of Web API application. Web APIs can be built in various frameworks such as Java and Spring Boot, Ruby on Rails, or of course, ASP.Net Core Web API.

Nested MVC Applications

One point I’ve often noticed is that what we really have with a full stack application using ASP.Net Core Web API on the backend and Angular on the front end is a nested MVC application.

If the backend Web API application is in fact an MVC application, and Angular, acting as the View itself implements a type of MVC, then what we end up with is in fact a nested MVC application. I just wanted to leave you with my take on that before we move on.

< Prev
Next >

Leave a Reply