Practical .NET

Insider: Design Patterns and Dynamic Runtime Configuration

Peter Vogel helps you understand the benefits of dynamic loading at runtime.

• By Peter Vogel
• 08/10/2011

On a couple of occasions I've used Reflection to load classes at runtime rather than add references to those classes at design time. I won't say that it's made my applications easier to deploy, but I think that dynamic loading falls naturally out of object-oriented design principles.

When a class performs part of its work by calling a method on another class, the process is called delegation. Creating an application by assembling several DLLs is referred to as composition (if the objects involved can survive the application, the technique is called aggregation).

I like composition because it's a critical part of achieving one of the goals of object-oriented design: To reduce the logic in your application. Every additional logic statement (If…Then, Select) increases the complexity of your application, increasing both the time to debug/test the application and the chances that something bad will slip into production. Those problems, it seems to me, are harder to track down than a missing DLL.

Most design patterns, for instance, allow you to replace logic with polymorphic classes: Load the right class and everything just works. The Strategy pattern, for instance, revolves around passing a "strategy" class to another object which then calls methods on the strategy class. By swapping a different strategy class you can dynamically control what your application does when the methods on the strategy class are called. Other than deciding what strategy class to pass, no logic is required. The Adaptor pattern allows one class to manipulate any other class by loading an intermediary object: Replacing the adaptor class at runtime allows your application to work with any other class. Again, other than picking the right adaptor, no logic is required.

While composition does reduce the complexity of your application, it does so at the expense of increasing the complexity of picking the right pieces. Another design pattern kicks in here because you can often isolate the code that picks and creates the objects into factory classes that have only one job: creating and returning the right class. Again, a more manageable problem than dealing with complex logic errors.

Dynamic loading goes one step further by deferring the decision as to what class you'll use to the last possible moment: Runtime. With dynamic loading, you configure your application's functionality by loading the right class based on information available when the application is executing (e.g. from a configuration file or just what evidence is lying around in the environment).

I used dynamic loading most extensively for an application that I built for a client that my client then sold onto their customers. My application received data from a number of sources and decided what class it needed to process that data by examining the incoming data as it arrived. Based on what it found in the data stream, the application searched through a table that specified what assembly and class should be used to turn the data into information. If a customer needed to process a new input stream, they just dropped a new DLL into the application's folder and added an entry to the table. Effectively, we created the potential for a third-party market based around this application.

We started this application some time ago, so I built it all with Reflection; if we ever upgrade it, I'll rewrite it using the Managed Extensibility Framework (MEF) that comes with Microsoft .NET Framework 4. Regardless of which tool is used, though, all we need to distribute to developers interested in creating new DLLs for this application is a reference DLL and a page of documentation.

I've just wrapped up working for that client (at least for the foreseeable future). In honor of that event, I'm going to devote my next Practical .NET print column to the .NET Framework tools that let you implement dynamic runtime composition.