From the course: Learning ASP.NET Core MVC

Understand the model-view-controller (MVC) pattern

From the course: Learning ASP.NET Core MVC

Start my 1-month free trial

Understand the model-view-controller (MVC) pattern

- [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. For example, web pages in the early days of the web contained markup that combined the layout, style, and even data all in the same document. Over the years standards based on separation of concerns emerged and what was once one document is now split into three parts: an HTML document, which mainly focuses on the structure of content, one or more CSS style sheets that define the style of the document, and JavaScript to attach behaviors to the document. In the context of the Model-View-Controller pattern, separation of concerns is used to divide the application into three key components. Models, Views, and Controllers. The view is exactly what it sounds like. It's the part of your application that the user sees and interacts with. In a web application the view is everything that gets rendered down to the browser; HTML, CSS, and JavaScript. The view's single responsibility is to deliver a high quality, good-looking user experience to the user and nothing else. 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.

Contents