Lying to ASP.NET Core: Part 1 of x &#8211; Introduction

Change occurs all the time. As programmers we write rules and logic, but knowing that the requirements of today aren’t going to work in the business world of tomorrow is part of the deal. We allow for that, we write around it.

But these changes are normally regarding the fundamental flow of the process we’re writing. How that process is exposed to our end users on a website? That requires constant finesse to align with business activity. A word change here or there can drastically alter perception, updating a piece of text on a site to be compliant with the latest laws or regulations can be a time critical process. And through all these changes, we don’t want the functionality of the site to be compromised – we keep content as separate as we can.

Now obviously for those sites that are heavily content driven, that handle large numbers of updates on multiple pages, you try and find a CMS that can handle the work. But that’s a large amount to add to your UI if the areas of possible change are small, and do you really want your page to have to check for new content time and again when the content is the same for every user and may not change for weeks?

What if you could tweak the page at the point where ASP.NET compiled your view? What if you could pretend that the business content was there in your page from the start? Well that’s where IFileProvider comes in.

In previous versions of ASP.NET this functionality was known as VirtualPathProvider – but the idea was the same. A layer between the request for a file or directory, and ultimately the stream that represented the file contents. A File Provider can lie to ASP.NET about whether a page or view is really there, and what’s inside.

The structure of IFileProvider is as follows:

namespace Microsoft.Extensions.FileProviders
{
    public interface IFileProvider
    {
        IFileInfo GetFileInfo(string subpath);
        IDirectoryContents GetDirectoryContents(string subpath);
        IChangeToken Watch(string filter);
    }
}

I won’t go into a lot of detail here, the naming is mostly self explanatory.

GetFileInfo gives the calling code access to information about a single file path, relative to the web root. Calling code can find out if the file exists, when it was last modified or retrieve the stream that represents it.
GetDirectoryContents does exactly what the name suggests, the return type of IDirectoryContents is an IEnumerable along with an existence check.
Watch is the most complicated of the three methods. The calling code asks the provider to notify it when any of the files matching the filter parameter are altered. This is done by registering a callback against the IChangeToken object that is returned by the watch method. It’s worth noting at this stage that filter can be an exact path, or a wildcard based pattern.

We’ll go into more detail of each of these methods in later articles but hopefully for now you can see that although small, IFileProvider gives you a powerful ability to mimic or supplement the ASP.NET file system; even representing the complexities of several large websites without requiring actual web files.

I have some ideas for a more complex example like this toward the end of this series, but for next time we’ll look at a smaller change – storing business information within a database (in my case AWS DynamoDB) and how we can use it to alter the default File Provider in order to supplement the information within my website at compile time.

Lying to ASP.NET Core: Part 1 of x – Introduction

March 10, 2016