Cowboy \(Gregory A. Beamer\)
10/11/2002 9:42:00 PM
While static and Singleton are similar, they are different approaches. You
use static to avoid instantiation when creating an instance does not make
sense. A singleton guarantees that only one of an object can be instantiated
at any one time. The most common use of a singleton is for application
settings, or for objects like a printer queue, et al.
The static method approach is very useful when you have items that do not
require an object. If you have objects that are only methods, they are good
candidates to look at for a static object type of approach. As soon as
properties are thrown into the mix, the 100% static approach becomes less
useful.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Author: ADO.NET and XML: ASP.NET on the Edge
****************************************************************************
****
Think outside the box!
****************************************************************************
****
"bijoy" <bijoy@nospam.com> wrote in message
news:18fa01c270c0$969b5830$35ef2ecf@TKMSFTNGXA11...
> We are not sure whether we am getting this right regards
> the Singleton Object.
>
> Intially we thought it would be a good idea to have our
> Business & DAL objects
> as Singleton Objects with static methods so that there
> isnt an overhead to instantiating them.
> But decided against that pattern after hearing that all
> such static methods will just have a single thread of
> execution is this true and wouldnt service more than one
> client at any given time.
>
> What are the pros and cons of using such a design
> approach.
>
> Will there be any scalability issues since there is just
> one instance maintained in a Singleton approach.
>
> Well the Application blocks helper classes from Microsoft
> seem to follow this approach.
>
> we are worried whether such objects will be able service
> multiple client requests simultaneously
>
> Any sample illustrations would be higly regarded
> Regards
> Bijoy
> .