Our new CMS written using ASP.NET/MVC

Posted on 4/16/2009

Introduction

Brick River has recently redesigned its web content management system using the ASP.NET MVC framework. The purpose of this document is to describe the issues with the previous version of the system and to explain how ASP.NET MVC was extended to address these issues.

Business Case

Brick River has 29 customers who manage their websites using a standardized content management system. The customer base share similar needs and as a result a common codebase is in use.

This code has been developed over the years in classic ASP. It has allowed significant sharing of functionality while minimizing maintenance costs by emphasizing uniformity.

The functionality, stability and maturity of the existing application represents a significant asset for the organization. But as the system has evolved a number of issues have developed.

• Classic ASP is no longer an attractive development environment
• Customer specific code is conditionally executed within the central codebase

There is too much value in the existing code to consider abandoning it when moving to ASP.NET. The complexity of the existing code is such that a conversion from Classic ASP to ASP.NET is not feasible. The volume of the existing code is such that a rewrite is not possible either.

Customer specific variations are coded as exceptions in the main codebase. Over time the number of these exceptions has grown making the code less manageable. It is difficult to identify specific customer customizations as they are included in the main code.

A solution was required that would meet the following objectives

• Move into a newer development environment
• Allow centralization of common code
• Allow decentralization of custom code
• Allow use of existing codebase to preserve investment
• Present existing code using new framework. Simple coexistence would increase the burden of ongoing management.

ASP.NET MVC

Brick River chose to base their next generation product on ASP.NET MVC. This programming structure encourages a conformity of coding style that allows functionality to be easily shared between customers implementations.

In ASP.NET MVC a request for a page is routed to a Controller. The Controller then takes the appropriate Action. The Action then returns a View which represents the presentation of the page.

Each of these steps is coded in a standardized way using the MVC framework. This allows us to override or extend each step on a per customer basis.

Customer specific code inherits from the central codebase. This gives each site the entire feature set of the central code.

Customers can also override or extend specific items in the central codebase using the build in inheritance model of .NET.

These custom modifications shown in orange, are separate from the from the central codebase. This allows modifications to be easily maintained in a separate area for a specific customer.

When new functionality is added to the central code it is immediately available to all customer sites. A customer's site is the sum of the central code and their customizations, as shown in this diagram.

The structured nature of ASP.NET MVC and the way in which controllers and actions are articulated in the codebase promotes a style of design that allows common functionality across our customers.

The biggest differences between customer sites tend to be in the aesthetics rather than the function. The use of Master pages in ASP.NET does solve many of these issues. Customers each have their own distinct master pages that allow the site to be presented according to their design.

There are times when pages or portions of a page must be made specific to a customer. Brick River extended ASP.NET MVC to manage this requirement.

In ASP.NET a page is represented by a View. A View can include one or many Partial Views that represent sections of the page.

Views and Partial Views are stored in a central repository. When a view is used the usual ASP.NET MVC search semantics are observed to locate the view in the customer's own site. If the view is not found the central version is instead used. This allows a customer to override views on a page by page basis.

The central version of a view is displayed by default. Views are optionally comprised of Partial Views as shown in this diagram.

A customer can provide their own view. The customer view, shown in orange, takes precedence and is rendered in place of the central view. The partial views, shown in green, are still coming from the central repository. These views are not defined for this customer, so the central partial views are instead used.

A customer can also override a partial view. The normal view processes as normal , but instead of rendering the central partial view it renders the customer specific partial view.

This is shown on above. The customer specific site needs to override the first partial view in the page. This partial view is therefore defined at the customer level and so takes precedence over the central version.

Customer specific and central views or partial views can be used in any combination. In the example above all page content is being rendered with customer specific views.

This allows customers to have custom functionality which does not exist at all in the central repository.

Use of existing Classic ASP Code

Brick River has an extensive base of existing Classic ASP code. This needed to be presentable using the new framework without requiring a complete rewrite. At the same time, changes to Master pages and page views should be reflected in the classic ASP sections of the site.

The processing of classic ASP code using the framework happens as follows.

1. {page}.asp is defined as a route at application startup. This preserves the existing URL so as not to break links, etc. The page name, without the .asp extension, is passed to the controller action.
2. The request is routed to the Classic controller Page action. This controller action is also available as /classic/page/{page} allowing friendly URLs to optionally point to classic pages.
3. The controller looks at the ASP.NET session to see if we have saved a classic ASP session ID.
4. An Http Web Request is created. It's cookies are set to provide the session ID, if found. The page entity is also forwarded to the request for form processing.
5. The classic ASP application is called.
6. The Http Web Response now has the output from the Classic ASP page.
7. The Classic ASP Session ID is retrieved from the response cookie and stored in the ASP.NET Session for future reference.
8. The controller now has the page content. It can preprocess the page if necessary before dispatching it to the view.
9. The controller dispatches the content to the view. This can now be rendered using the current site design.

This method will allow us to gradually move the application to ASP.NET MVC over time.

Conclusions

Brick River has leveraged ASP.NET MVC to significant benefits for the organization.

• Features are implemented in a consistent way
• Consistency promotes reuse
• Customer specific code is managed in a decentralized way.
• Investment in the existing codebase is preserved