I'll have to get back to you on monday about that... I have a long weekend.

>Vb forum...you mean "shared". But anyways, how are they creating Singleton classes?
>
>>I'm glad the reason isn't obvious and I'm missing it. The way they are using it, I wonder why they didn't just make all of their method static instead. Oh well. I'm still trying to fight the best-way to do it architechure-wise battle, and so far it seems to be winning.
>>
>>>As the name implies Singleton means you only want one object of a particular class type running in your system. I think the best, most straight forward example is a connection to a database. If one already exists you don't want to establish another one.
>>>
>>>I could see where someone would think it would make sense for a business logic class to be a Singleton. But at the same time I could, and actually have seen these types of classes set up to be Singletons, and having tough to find intermittent bugs because of it.
>>>
>>>For example, since the class is a Singleton, all fields in the class only have 1 value used by all calls to this class. If any of those fields are the results of calculations, you could have a real timing issue on your hands. If you have logic to do something if the total invoice is above $10,000, and one outside method calls the Singleton calculation then calls the Singleton method to check the value of the calculation, while another instance of the Invoice class also calls the calculation, the first instance of the Invoice could see the result of the calculation for the second call to the Singleton. And incorrectly believe the 1st invoice is above $10,000.
>>>
>>>>Can somebody give some good real-world examples of where it is appropriate to use a Singleton pattern in a .NET application? One application I inherited with suspect architecture has every business logic class set up to use the singleton pattern. What are the advantages of this other than not having to instantiate a new object everytime I want to access business logic?
>>>>
>>>>Thanks!