Join Jess Chadwick for an in-depth discussion in this video Understanding the MVC pattern, part of Up and Running with ASP.NET 5.
- View Offline
- At this point in the course, I've shown you some of the basic building blocks of an ASP.NET 5 web application by simply responding to a request with some simple logic and static files, but all I've really demonstrated so far is the core platform that ASP.NET provides. Sure, we could build a web application by defining series of middleware endpoints, but there is an easier way. What we need is a framework that we can build on top of that that takes care of all the mundane plumbing code for us and let's us focus on writing our application logic instead.
In my experience, the ASP.NET MVC framework is a great choice. What is ASP.NET MVC? Well, to answer that, I'm going to take a step back and define the MVC or Model-View-Controller pattern that it was named after. The Model-View-Controller 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 data access 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.
In other words, your goal should be to make the view as pretty and as dumb as possible, relying on the controllers and models to take care of all 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 actually call back to the controller in order to execute logic that's outside of the view's responsibilities. Be careful here, though. 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 of 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 to react perhaps by first executing some validation logic. If the validation exceeds, the controller will then call the data access component to save the blog post. But 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 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 the 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 of your business logic lives, logic such as business processes, validation rules, or even the logic of integrating with other systems. MVC applications with 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'm defining the term model in the context of an ASP.NET web application, if I'm following 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 really don't need to worry about creating a model that could be used anywhere, but as far as separation of concerns and good design goes, it's a very good goal to aspire to. So if that's the MVC design pattern, what is ASP.NET MVC? Well, ASP.NET MVC is Microsoft's implementation of the MVC design pattern on top of the ASP.NET 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 a web application consisting of models, views, and controllers with a strong separation of concerns.
In this course, I'm going to be talking about the sixth version of ASP.NET MVC. Don't be fooled by the version number, however. This version of the ASP.NET MVC framework, like ASP.NET itself, has been rewritten from the ground up. If you're at all familiar with previous versions of the framework, however, don't be too concerned. You may have to learn a new API, but it should come easy since the concepts are exactly the same. The term that Microsoft folks like to use is concept compatible. For example, if you were used to there being a context property on your controller class, that hasn't changed.
There still will be a property named context that represents the context of the current request. However, it's a completely different type than it used to be. These changes definitely take some getting used to, but after a little while, many folks who were familiar with the previous versions of ASP.NET MVC do find working with this new version second nature again. Now that I've got all those high-level concepts out of the way, let's get back to the good stuff. Head on over to the next video in which I'll show you how to add the ASP.NET MVC framework to your application and start implementing a loosely coupled application.
- Understanding ASP.NET 5's new request processing pipeline
- Downloading client-side libraries using Grunt and Bower in Visual Studio
- Adding ASP.NET MVC 6 to your application
- Handling web requests with controllers
- Rendering dynamic views with Razor markup
- Using Entity Framework to write and read data to a database
- Using TagHelpers to create simple dynamic HTML forms
- Registering and authenticating users with Identity services
- Dynamically update portions on the server using partial rendering
- Using dynamic routing logic to customize URLs
- Exposing data with web APIs
- Leveraging custom configuration and logging
- Increasing application maintainability with dependency injection