I am working on a web application which I need to localize and internationalize. It occurred to me that I could do this using a dependency injection framework. Let’s say I declare an interface ILocalResources (using C# for this example but that’s not really important):
interface ILocalResources {
public string OkString { get; }
public string CancelString { get; }
public string WrongPasswordString { get; }
...
}
and create implementations of this interface, one for each language I need to support. I would then setup my DI framework to instantiate the proper implementation, either statically or dynamically (for example based on the requesting browsers preferred language).
Is there some reason I shouldn’t be using a DI framework for this sort of thing? The only objection I could find myself is that it might be a bit overkill, but if I’m using a DI framework in my web app anyway, I might as well use it for internationalization as well?
If you cannot use an existing resource framework (like that built into ASP.Net) and would have to build your own, I will assume that you at some point will need to expose services that provide localized resources.
DI frameworks are used to handle service instantiation. Your localization framework will expose services providing localization. Why shouldn’t that service be served up by the framework?
Not using DI for its purpose here is like saying, “I’m building a CRM app but cannot use DI because DI is not built for customer relations management”.
So yes, if you’re already using DI in the rest of your application, IMO it would be wrong to not use it for the services handling localization.