Storing an object to use in multiple classes

I am wonder开发者_如何学Going the best way to store an object in memory that is used in a lot of classes throughout an application.

Let me set up my problem for you:

We have multiple databases, 1 per customer. We also have a master table and each row is detailed information about the databases such as database name, server IP it's located and a few config settings.

I have an application that loops through those multiple databases and runs some updates on them. The settings I mentioned above are updated each loop iteration into memory. The application then runs through series of processes that include multiple classes using this data. The data never changes during the processes, only during the loop iteration.

The variables are related to a customer, so I have them stored in a customer class. I suppose I could make all of the members shared or should I use a singleton for the customer class? I've never actually used a singleton, only read they are good in this type of situation. Are there better solutions to this type of scenario?

Also, I could have plans for this application to be multithreaded later.

Sorry if this is confusing. If you have questions, let me know and I will answer them.

Thanks for your help.

---

For this I would recommend using a pattern called "dependency injection", which in this case means you would pass in the shared variables each customer needs via either the constructor or a property that you set after construction. Preferably you would define the variables as interfaces, so that later you can drop in a different implementation of the interface when you do unit testing.

If you need thread safety, you can bake that into the accessor methods/properties.

---

There shouldn't be anything wrong (I think) in just using a local instance of your customer configured with the details required as properties (or public fields). Even if you were to switch to using this as a multi-threaded configuration, each active process of applying updates to a particular database should be done in a single thread and then return once that task is complete, so there is no need to have the instance data shared (or use singleton). Maybe just provide the process-specific data in parameters to a method which can be invoked on a worker thread?

Dependency injection is probably a good way to look at it also.

---

Storing this data in a cache on the system is going to be the best bet I think.

Now how you do this depends on what you're going to be doing. Is the app multi-threaded? Is it going to update this customer data frequently or only on startup?

If the app isn't going to be multi threaded a singleton will do exactly what you need. However if it is multi threaded there are some things to think about. If you plan on mostly reads with little updating and the updates are quick and infrequent a thread safe singleton would work just fine. However if you're going to be doing lots of heavy updates even a thread safe singleton can quickly run into race conditions.