ASP.NET MVC

Introduction

ASP.NET MVC introduces a very different development model. Most people would agree that it is more testable, promotes a separation of responsibilities - views for user interface, controllers for business logic – and is much closer to the HTTP protocol, avoiding some magic that Web Forms employs, which, although useful, can result in increased complexity and decrease of performance.

Note: Nick Harrison wrote ASP.NET MVC Succinctly for the Succinctly series; be sure to read it for a good introduction to MVC.

Branding

Here we will explore three branding mechanisms offered by MVC:

• Page layouts: The equivalent to Web Forms’ master pages, where we shall have a different one for each tenant.
• View locations: Each tenant will have its views stored in a specific folder.
• CSS bundles: Each tenant will have its own CSS bundle (a collection of tenant-specific .css files).

Page layouts

MVC’s views have a mechanism similar to Web Forms’ master pages, by the name of Page Layouts. A page layout specifies the global structure of the HTML content, leaving “holes” to be filled by pages that use it. By default, ASP.NET MVC uses the “~/Views/Shared/_Layout.cshtml” layout for C# views, and “_Layout.vbhtml” for Visual Basic views.

The only way to use a page layout is to explicitly set it in a view, like in this example, using Razor:

Code Sample 52

In order to avoid repeating code over and over just to set the page layout, we can use one of MVC’s extensibility points, the View Engine. Because we will be using Razor as the view engine of choice, we need to subclass RazorViewEngine, in order to inject our tenant-specific page layout.

Our implementation will look like this:

Code Sample 53

In order to use our new view engine, we need to replace the existing one in the ViewEngines.Engines collection; this should be done in some method spawned from Application_Start:

Code Sample 54

Finally, we must make sure our views set the page layout (Layout property) from ViewBag.Layout, which is mapped to whatever is returned in the third parameter of FindView:

Code Sample 55

View locations

By default, the view engine will look for views (.cshtml or .vbhtml) in a pre-defined collection of virtual paths. What we would like to do is look for a view in a tenant-specific path first, and if it’s not found there, fall back to the default locations. Why would we want that? Well, this way, we can design our views to have a more tenant-specific look, more than we could do just by changing page layouts.

We will make use of the same view engine introduced in the previous page, and will adapt it for this purpose:

Code Sample 56

This requires that the view engine is configured with the usePhysicalPathsPerTenant set:

Code Sample 57

CSS Bundles

CSS Bundling and Minification is integrated in the two major flavors of ASP.NET: Web Forms and MVC. In Web Forms, because it has the themes mechanism (see Themes and ), it is probably not much used for branding, but MVC does not have an analogous mechanism.

A CSS bundle consists of a name and a set of .css files located in any number of folders. We will create, for each of the registered tenants, an identically-named bundle containing all of the files in a folder named from the tenant configuration’s Theme property under the folder ~/Content. Here’s how:

Code Sample 58

This method needs to be called after the tenants are registered:

Code Sample 59

Tenant “abc.com” will get a CSS bundle called “~/abc.com” containing all .css files under “~/Content/abc.com”.

This is not all, however; in order to actually add the CSS bundle to a view, we need to add an explicit call on the view, like this one:

Code Sample 60

However, if we are to hardcode the tenant’s name, this won’t scale. This would be okay for tenant-specific layout pages, but not for generic views. What we need is a mechanism to automatically supply, on each request, the right bundle name. Fortunately, we can achieve this with an action filter:

Code Sample 61

This action filter implements the IActionFilter interface, and all it does is inject two values in the ViewBag collection, the tenant name (Tenant), and the CSS bundle’s name (TenantCSS). Action filters can be registered in a number of ways, one of which is the GlobalFilters.Filters collection:

Code Sample 62

With this on, all we need to add custom tenant-specific bundles on a view is:

Code Sample 63

Security

We might want to restrict some controller actions for some tenant. MVC offers a hook called an authorization filter that can be used to allow or deny access to a given controller or action method. There’s a base implementation, AuthorizeAttribute, which grants access only if the current user is authenticated. The implementation allows extensibility, and that’s what we are going to do:

Code Sample 64

When applied to a controller method or class with one or more tenants as parameters, it will only grant access to the specified tenants:

Code Sample 65

The next chapter describes another technique for restricting access to resources without the need for code.

Unit Testing

Testing MVC controllers and actions is straightforward. In the context of multitenant applications, as we have been talking in this book, we just need to set up our test bench according to the right tenant identification strategy. For example, if you are using NUnit, you would do it before each test, in a method decorated with the SetUpFixtureAttribute:

Code Sample 66