This course explores how to extend and customize the MVC framework to better solve common development tasks. MVC is designed with extensibility in mind and leveraging this flexibility can help solve tasks faster and far more effectively.
The goal of this course is to teach developers how to customize and extend the MVC framework to meet their needs. MVC is built with powerful extensibility in mind and leveraging this flexibility can help solve tasks faster and more effectively. This course explores the extension points developers are most likely to work with in a real project and which provide the most value in the shortest amount of time. Understanding these features is crucial to building maintainable, properly structured MVC applications.
Alex Wolf is passionate about software development and mastering new technologies. He has several years of experience working almost exclusively with the .NET Framework and related platforms. Alex is also a Microsoft Certified Professional in both MVC Application development and HTML 5 technologies. He loves learning new things!
Overview Hi. I'm Alex Wolf, and welcome to this course on how to improve your MVC applications using 10 extension points. Now the MVC framework is designed heavily with extensibility in mind, and by the end of this course you should feel comfortable leveraging that to your advantage. We'll explore common challenges or shortcomings that you might encounter when working with the framework defaults, and just how to customize components to really take control of your application again. So let's begin by discussing in more detail just the benefits of this course and whether it's a good match for where you are as a developer right now.
Improving Data Availability with Custom Value Providers In this module, we want to discuss Custom Value Providers, which are very closely integrated with model binding. Value Providers are the type of extension point that you probably won't have to build that often, but they can be extremely helpful when the situation does arise. Let's look at why we might want to implement this component using the Paladin application that we've been working with. Development on the insurance quote app is going well, but new requirements have caused an interesting issue to surface. There is specific Http Header information that the developers would like to capture for certain requests and persist to the database. For example, they might like to save information such as the UserAgent string associated with an applicant session. They might also like to bind Http Header information to some type of base model or logging class so that that information gets saved with every request. Right now the team would have to manually extract values out of the request object inside of action methods and assign these values to the models. They want to simplify this process to be able to add specific properties on existing models and have those be auto-populated with Http Header information at the time of model binding. We can solve this problem by implementing a custom Value Provider. These components can provide additional data to the Default Model Binder for this type of task, so let's discuss Value Providers more in the next lesson.
Influencing Action Method Execution Using Custom Selectors In this final module, we want to focus on a few tasks and extension points related to controllers. More specifically, we'll discuss Action Name Selectors and Action Method Selectors, which allow us to customize how controller actions are selected to handle a request. Now there's also a bit of light refactoring we want to take care of in our controllers just to make our code a bit cleaner. We can accomplish this by using an additional base layer controller, which we'll review towards the end of the module. At the moment, we want to address another issue that has surfaced for Paladin Insurance. The company has an existing mobile app that was completed long before this new application was started. This mobile app displays a few pages from their website inside of embedded web views, however, the mobile app is branded with the same design as the old website that our new insurance application is replacing. Our new site features updated graphic design and branding, as well as different URLs and slightly different data for those pages. Management still wants to display those old pages in the mobile app, since it will not be updated with the newer branding for some time, but they don't want those pages to be accessible via a normal desktop or mobile browser. Requests from the mobile app do include a custom Http Header to identify their origin, and the developers are really hoping to utilize this to solve the problem. Well it turns out, we can easily accomplish this by extending the action method selection process, so let's discuss our options for this in the next lesson.