Stack overflow suggested that this question my be better suited here. I normally work in c#, but I'm working in a vb.net net application currently. So feel free to respond with vb.Net or c#...
Essentially I have a singleton that does all of the heavy lifting of getting global settings which are stored in the database; but there is an interface (dialog form) that allows those settings to change.
So what I did was create a singleton which on the first instantiation (only) runs the public update method. If, however, a user opens the settings dialog, the singleton is instantiated and the update command is invoked separately just in case the user made changes to the settings in the settings dialog... its the only place where I run the Update method outside of the initial instantiation of the singleton object. Conceivably another errant developer could irresponsibly run the Update method over and over again, but it would not harm anything except slow down the application--and this is the main reason I wanted to use a singleton, because there are cases where with calls to the settings is made hundreds if not thousands of times in loops; which would really slow down the application, and also the settings are being called from many random locations depending on what the user does... why don't I use a simple DTO, well, that's described below.
The other crazy thing about this application is that multiple "environments" can be running in the same thread, each with completely different settings (long story). The way the prior developers handled this was by making a call to update a settings DTO every time there was a possible switch or change in the settings or "environment", or upon starting up the application. On a search there are around 40 locations... seems nuts to me. This is on top of the hundreds of calls were the DTO is accessed. I want this singleton to do the heavy lifting and verify which environment the app is in and retrieve the settings only once from the database--except on that one occasion with the settings dialog I mentioned above, where the Update method is invoked.
End result, one nutty singleton... Below is a simplified version of the code. Basically, I'm asking whether is this a reasonable pattern, or is there a better one for this? Note that one potential downside to my solution is that I still need to make a database call, as a check to the current database, every time this class is instantiated. Thanks for the feedback.
Public Class MySingleton Private Shared _Instance As MySingleton = Nothing Private _ExampleSetting As String Private _CurrentDatabase as DBDatabase Public Shared ReadOnly Property GetInstance() As MySingleton Get If _Instance Is Nothing Then _Instance = New MySingleton() ElseIf _CurrentDatabase <> GetCurrentDataBase() Then _Instance = New MySingleton() End If Return _Instance End Get End Property Public ReadOnly Property ExampleSetting As String Get Return _ExampleSetting End Get End Property Private Sub New() Update() End Sub Public Sub Update() _CurrentDatabase = GetCurrentDataBase() _ExampleSetting = _CurrentDatabase.GetSetting("exampleSetting") End Sub End Class