Introduction

If you’ve ever worked on windows vs. web environments, you see how there can be vast differences between the two environments. In the web environment, you have to worry about retaining state across postbacks, whereas windows environments don’t necessarily have the same concern. Windows environments have to manage clicks, key presses, and many more events, while the web is less concerned; the browser handles certain interactions within its controls such as tabbing, focus and blurring, etc.

Despite the two differing development realms, in the business application realm, the two can come closer than we realize, if we design our applications in a specific way. If we embrace design patterns for all that they offer, we can reduce the amount of code to handle differences between multiple environments. If you leverage all that object-oriented programming has to offer, there can be great gains in terms of reusability as we’ll examine in this article.

The concepts you learn here can be reused across environments. For instance, we could do something similar when we talk about mobile environments, embedded systems, or even Silverlight applications, depending on the requirements and the needs available.

While this idea can work for applications performing much different work, the closer the systems function to each other (the closer the windows application does the same thing as the web application), the greater similarities you will find in your application development, leading to the less amount of work you actually have to do.

Centralizing Access

The key way to create common functionality between multiple environments would be something similar to the Singleton design pattern. The Singleton is a nice design pattern, but there can be some considerations to take into effect with this pattern in the web realm. First, even though static objects can be retained across postbacks, at some point, you don’t have full control over how long that data lives. Plus, many people use the web application simultaneously, whereas one person generally uses the instance of the application (because the code is on the client for a windows app, where the code is on the server for the web app, excluding the ideas of AJAX).

Be that as it may, I like to create a central object that exists at the root of the application. This object could be considered the context of the application (logically speaking). In Windows, global objects sit at the root of the windows application potentially (at the MDI for MDI-based applications, or at the application level for WPF applications, for example).

For the web application, this object could be static, could be cached, or could be reloaded on every page load, depending on what it needs to do. This object can take advantage of the global objects within the web environment. Most notably, these objects are:

• Page – The core class for all ASP.NET pages. I highly recommend creating a custom Page class for all of your ASP.NET pages, which can expose common custom settings throughout the entire application.
• HttpContext – The core context object class for HTTP requests. Maintains references to the Request, Response, and Server objects. The Page object, in some cases, returns the references provided via HttpContext. To access HttpContext, call HttpContext.Current. The HttpContext class maintains a reference to the executor of the request – the Page class – via a Handler property.

With any approach you take, the key is starting off with a base class that will bridge the difference gap. A possible option could be to create a base class as shown below:

Listing 1: Common Settings

Listing 1 contains the base class for an ApplicationManager. This class is a base class that will be responsible for web/windows specific implementations. Some of the properties will be implemented in the base class, but some of the features are marked abstract and allow the derived classes to implement them. For instance, the CurrentUser property returns a custom class containing the user information about the user logged in. The UserInformation class is a class that contains the core information about a user, something we’ll explain later.

Providing Web-Specific Implementations

The core derived classes that will use this are one for the web application, and one for the windows application. I’m going to omit the windows side for the moment, moving on to a web solution for the application manager listed below.

Listing 2: Creating a Web-Specific Implementation

This web manager implements these features however it needs to, for its own purposes. For instance, the current user object stores information about the user record. So the user information can be used in both the web and the windows environment, a new UserInformation object is created to store this information, rather than exposing the MembershipUser record and forcing the architecture on both environments. This new UserInformation object is security system agnostic, and only stores the information needed by the application. As another example, the Title property stores the title of the application, which may vary between web or windows environments, and can be customized.

This works nicely, but what about more complicated examples? For instance, what if we need to implement caching between the two? There are a couple of options. We could use an approach like we did for the user information; we could create an abstraction between the two. We could create a CacheManager class that uses the System.Web.Caching.Cache object in the web environment, along with Enterprise Library’s caching block for the windows environment. It could even be made configurable using the provider pattern, so that you can swap one caching solution out with another on the fly. This could look like:

Listing 3: Caching

Now we can use this component for caching in multiple scenarios. The ApplicationManager can return a reference to this component either by returning the reference as a property, or via a more dynamic approach, such as a GetService method. We could do something like:

We can reference the object by its base type (CacheManager), and retrieve the specific implementation in a generic way. The solution could have been to use an abstract property in the ApplicationsManager base class, and return our web-specific implemention in WebApplicationsManager; that would have worked fine. This implementation allows for a more dynamic switching of implementations as needed, and even allows a manager to swap implementations during runtime (through some other supporting methods).

What about MVC?

It may seem that this implementation may be web-forms specific, and exclude MVC. I don’t think it does; in MVC, this sort of code would be accessed via the controller code, or possibly the model, depending on what type of data is stored. Your controllers can instantiate any object to do any type of work, and this is another object to assist with that work.

Conclusion

I highly recommend trying to create a common architecture that’s not dependent upon the web or windows environment. By doing so, a dependency is partially eliminated, and a higher level of maintainability/code reuse is achieved very easily. While you can’t create a common codebase for both (the web and windows each has their own unique attributes that the other doesn’t share), if you can achieve a commonality for as much of your business/framework code as possible, you will find a greater value for a lesser effort.

Note that this solution requires some additional work, to abstract each interface accordingly. For instance, to abstract caching to work with any environment, it requires some additional work and isn’t out of the box. I’m working on this personally in a framework of mine available at http://www.codeplex.com/nucleo. But good application architecture takes time and ingenuity, as all good software development requires.

About Brian Mains

Brian Mains is an application developer consultant with Computer Aid Inc. He formerly worked with the Department of Public Welfare. In both places of business, he developed both windows and web applications, small and large, using the latest .NET technologies. In addition, he had spent many hou... This author has published 73 articles on DotNetSlackers. View other articles or the complete profile here.