Easy Localization using Factory Methods in .NET

ASP.NET 2.0 has some great localization features that make it easy to build multilingual web applications. The problem comes when you need different business logic for different countries, maybe to validate a local address or calculate shipping costs. You somehow need to get the application to behave differently based on a country code or the thread’s current culture setting.

For simple variations you can use separate configuration settings for each country. For example, a regular expression in web.config to validate a local telephone number. But if the logic is more complex then you might need a different plan.

An obvious approach is to use conditional switch/select-case statements, like this:

switch (countryCode)
{
   case "FR":
   /* Logic for France */
   case "US":
   /* Logic for USA */
}

But for large applications this can quickly get unwieldy and difficult to manage. Adding a new country means finding every switch statement and adding a new case.

Instead, a good solution is the Factory Method design pattern. It makes your application much easier to maintain, and adding new countries is easy. Here’s a quick example that extends the idea of validating local postcode formats.

Class Diagram

These are the classes used, described below in more detail.

Step 1

Create an abstract class for performing local validation called LocalValidatorBase. This is a base class which can’t be instantiated. Add a method signature IsValidPostcode that takes a string and returns a boolean. Classes for various countries can now derive from LocalValidatorBase and override IsValidPoscode with custom validation logic.

(The LocalValidatorBase class can contain logic to share between all the subclasses, but if this isn’t necessary then you can create an interface instead of an abstract class called something like ILocalValidator.)

Step 2

Derive two local validation classes from LocalValidationBase called LocalValidatorAU and LocalValidatorDE, one for Australia and one for Germany. In each, override IsValidPoscode to perform country-specific logic for validating a postcode, maybe by checking the string length or matching against a regular expression. The details aren’t important here.

Step 3

Create a factory class to return the correct validator object for the current country setting. Add a static/shared factory method called GetLocalValidator that returns a LocalValidatorBase class. The magic of polymorphism means this method can return any class derived from LocalValidatorBase. Use a switch statement, or some other conditional logic, to return a new instance of LocalValidatorDE or LocalValidatorAU depending on a country code parameter or the thread’s current culture name.

Step 4

That’s all there is to it. You can now call the factory method to get the correct validator object for the current country.

// call the factory method to get a concrete validator
LocalValidatorBase validator = LocalValidatorFactory.GetLocalValidator();

bool isValid = validator.IsValidPostcode("12345");

The validation success depends on the rules in the object returned by GetLocalValidator, which will be different depending on the current country.