I have some global components I am not sure how to put them in design. Such as:
Settings class: it is interfacing the initial settings of the program, it could be app.config(1way), web.config(1way), hard coded values(1way), or sqldb(2way) behind the scenes.
Language class: it contains different language sets, and again, I could have some resx files(1way), hard coded values(1way) or sqldb(2way) behind it.
First question is, should I make these classes setter properties in dependency injection (I use Windsor):
public ISettings Settings {set;}
public ILanguage Language {set;}
Or should I make them ambient context:
string DoSomethingAndReportIt() {
//do something ...
var param = Settings.Current.SomeParam;
//report it ...
return Language.Current.SomeClass_SomeMethod_Job_Done;
}
I notice there are a few components in .net library that actually use ambient context pattern, e.g. System.Security.Principal, System.Web.ProfileBase, System.Thread.CurrentCulture ...
Do you think it is no harm to make my global classes such as Settings and Language to be ambient context classes? If not, why DI is preferred? Do they take more advantage in unit testing compare to ambient?
Second question is, if DI is better, (I have a feeling that the DI pattern is preferred), what is a good way to proxy the existing ambient classes such as Security.Principal or Profile to follow the DI pattern?