- [Instructor] At this point in the course I've shown you some of the basic building blocks of an ASP.NET Core web application using low-level APIs to respond to requests with simple logic and static files. What we need is a framework that takes care of all this mundane middleware plumbing code and lets us focus on writing our application logic instead. What we need is the ASP.NET Core MVC framework. In order to truly to understand the ASP.NET Core MVC framework, we must first define the design pattern that it was named after: The Model-View-Controller or MVC Pattern.
The MVC pattern is a user interface design pattern that promotes separation of concerns across multiple application layers. In other words, instead of putting all the View Logic, Application Logic, and Business Logic for an application in a single place, MVC promotes separating each of them into specific classes, each with a small, specific set of responsibilities. Separation of concerns is a powerful principle that is frequently used in the design of platforms and frameworks.
In other words, your goal should be to make that view as pretty and as dumb as possible, relying on controllers and models to take care of all of the smarts of the application and displaying the result. This diagram shows a dotted line from the view to the controller indicating that the view may call back to the controller in order to execute logic that's outside of the view's responsibilities. Be careful here. It's always tempting to make the view more intelligent than it should be but you'll want to avoid that at all costs as it typically results in application code that is more difficult to change and maintain.
You'll know you've done it right when you can completely throw away your view and start from scratch with relatively little effort because the real logic, the application, is defined elsewhere distributed between the controllers and the models. Controllers are the traffic cop of your application, controlling application workflow as the user interacts with the view. For example, I'll soon be showing you how to create a view that accepts the text for a new blog post and displays a button to create that new blog post in the system.
When you click on that button, the view will tell the controller about the text that the user has entered. But after that it's up to the controller to determine how to react; perhaps by first executing some validation logic. And then if the validation succeeds, the controller will then call the data access component to save the blog post. If the validation or the data access component fails, the controller will choose the appropriate view to display to the user depending on the error that occurred.
Notice how the controller spends its entire life orchestrating interactions between components. This is important and one of the biggest mistakes that a lot of developers make is making the controller too smart by defining application logic rather than orchestration logic. It's best to put all that application logic into the model and let it do the heavy lifting. The term "Model" has come to mean many different things over the years. Perhaps the most popular definition refers to the data structures that are used throughout your application.
And while the model certainly does define data structures, it's also much more than that. In the MVC pattern, the model is the heart of the application. It's where all your business logic lives. Logic such as business processes, validation rules, or even the logic of integrating with other systems. MVC applications with a good separation of concerns will contain a model layer that is completely isolated from the platform or environment that it's operating under.
In other words, though I am defining the term "Model" in the context of an ASP.NET web application, if I'm filing a strict separation of concerns, I could actually use the same exact model in a Windows Forms WPF or even a console application. Practically speaking, you won't really need to worry about creating a model that could be used anywhere, but as far as separation of concerns in good design goes, it's a good goal to aspire to. So if that's the MVC design pattern, what is ASP.NET Core MVC? Well, ASP.NET Core MVC is Microsoft's implementation of the MVC design pattern on top of the ASP.NET Core platform.
That is, it's a framework that is built on top of those core building blocks that I showed earlier in the course that helps you create web applications consisting of models, views, and controllers with a strong separation of concerns. Now that I've got all those high level concepts out of the way, let's get back to the good stuff.
- Building blocks of ASP.NET Core applications
- Creating a new project
- Responding to HTTP requests
- Serving static files
- Understanding the MVC pattern
- Handling requests with controllers
- Rendering HTML with Razor
- Rendering data, view markup, and view logic
- Creating HTML forms
- Validating form data
- Reading and writing from a database with Entity Framework
- Improving the user experience
- Exposing data with a web API
- Securing your ASP.NET application