Making sense of the ASP.NET Core MVC Design Pattern

#csharp #webdev #backend #architecture

MVC is a Software design pattern that is used to structure full stack web applications. Visual studio has incorporated frameworks, nuget packages, and libraries to fully support developers when creating MVC apps. This design pattern can be useful for applications in which the following operations are needed:

-Dynamically rendered client side web pages
-Server Side database(s)
-CRUD Actions
-User Authentication
-Authorization

To begin an MVC application, select all the necessary options needed from the templates that Visual Studio has listed inside the user. An ASP.NET Core Web Application will allow users to work cross platform and has a larger set of libraries for developers to work with. Next choosing the ASP.NET Core MVC option with individual user accounts will allow for developers to implement authenication. After the template of the project has been created, The programmer needs to understand the flow of data in order to properly write programs using MVC.

When creating MVC applications, you will always begin building your application from the server side, and then work your way into the client side to ensure that scaffolded classes have been created properly. Models are used in order to mimic real world objects. For example, earlier on in my bootcamp’s Cohort, we built a Car model for a Car Pro mvc application. That Car.cs file will model, or take on the role of, a real life car. Therefore, It will have its own properties that a real life car would have. Make, model, drivetrain, etc. The developer will set these properties to a certain type in order to properly store the values of the properties. Data annotations will be used to curtail data in a manner that is reasonable and easily digestible for both the client and any data structures that may hold onto this piece of data. Since this project will feature a car inside a lot, the car model will contain a foreign key as well as a navigational property to denote its parent. Using this technique of modeling real life objects, Visual Studio will allow us to scaffold a controller that will act as a middleman for the rest of the application.

Using Entity framework, scaffolding a controller from a model will allow the controller to perform CRUD actions, (Create, Read, Update, Delete). The results of the CRUD actions will then be seen inside the View, more on that aspect of MVC later on. As for the controller, CRUD actions are methods the controller uses in order to manipulate the data inside of the models. In MVC, there are two HTTP cycles used in the application, HTTPGET and HTTPPOST. HTTPGET is used whenever a view is being seen by the client for the very First time. For example, if a developer has created an Ecommerce website, the home controller will send an HTTPGET request to the Views file. The views file will send back the index view. Though its not denoted in the method, the very first time the client sees the index page, (denoted as [localhost/home/index]) it is by default an HTTPGET request.

The Views are the client side of the Application. The views will be where the clients will interact with the application. The first thing to understand about the view is the file structure. The home and shared views will always be present at the beginning of any application. The home views have been scaffolded by the home controller. The shared views allow developers to share certain aspects of websites along amongst multiple views. Navbars, sidebars, and many other navigation related components usually reside in the shared folder. Cars and Lots were scaffolded after the Cars and Lots models were created.

The view is responsible for rendering data based on the model that is declared. This is achieved by using a combination of tag helpers, Razor syntax, and lambda expressions. While inside of a view, the user may want to perform a create action. First, the view will show the create method that has the HTTPGET attached to it. Once all input fields inside the form have been completed and the user presses enter, then an HTTPPOST request will be sent to the View. There is a lot going on when a post cycle is being ran. First, the post cycle needs to be ran with an AntiForgeryToken. This validation catches any sort of malicious commands or scripts that could come from an authenticated user. Next, all the properties being created need to be set into the Bind. Think of the bind as a guest list. No name, no entry. All properties of the model, even if it has been set to hidden on the view, need to be inside the bind in order to create a new instance of the model.