Singleton's are not advised against. Singletons used in the wrong place or the wrong way are advised against.
Your entire question is screaming as the "correct" and "proper" example of when it is good to use a singleton.
If you diagram your design and a large number of your objects in your code point to the exact same instance of another object, and no second instance of that object is ever needed, then you have found the correct use for a singleton. From what you have described, you are in this situation.
Now, you could also use a static. The only difference between a static and a singleton is that a singleton isn't instantiated until first use. Since you probably have a login after load, you might as well wait until the first login attempt occurs to instantiate your singleton. So that is why you would use a singleton over a static.
public class GlobalSettings : IGlobalSettings
{
public static GlobalSettings Instance
{
get { return _Instance ?? (_Instance = new GlobalSettings()); }
} static GlobalSettings _Instance;
public GlobalSettings()
{
}
// More methods/properties here
}
Singletons can also work just fine in multithreaded applications with lock. See this article: http://msdn.microsoft.com/en-us/library/ff650316.aspx
Singletons are also very easy to Unit Test or use in IOC. Anyone who says otherwise just hasn't realized that you can simply use an interface to describe the singleton and then all your objects that use the singleton can have an instance of that Interface. I use lazy property injection as shown below unless an IOC libray is already in place. I wouldn't include the bloat of an IOC library just for this.
public static IGlobalSettings Settings
{
get { return _Settings ?? (_Settings = GlobalSettings.Instance); }
} static IGlobalSettings _Settings;
Or you can also have your IOC Controller/factory just return your Singleton instance every time as your interface.