Logging Class - Instance or Static

[Guest]

I have a logging component that I will access in other assemblies. So it was
brought up to me that I should pass an instance around to these components
instead of just making the logging class static. If I make it static I
wouldn't need to
pass an instance around. What is your take on this?

 

[Tom Spink]

I have a logging component that I will access in other assemblies. So it
was brought up to me that I should pass an instance around to these
components instead of just making the logging class static. If I make it
static I wouldn't need to
pass an instance around. What is your take on this?

Hi,

An important decision, and it depends on your needs. Does your class need
to retain state? How complicated is it? How memory-hungry is it?

 

[Guest]

Its a pretty simple class that will send emails, write to eventlog or to a
file. My thinking is if I pass an instance around and it gets passed down a
chain of about 3 classes then I will have multiple refs to my logging class
and I am wondering if that is the proper coding technique to be using here?

Does your class need
to retain state?

No my class doesn't need to retain state but if I make it static I can just
refer to directly from any where without having refs to it.

 

[wfairl]

I have a logging component that I will access in other assemblies. So it was
brought up to me that I should pass an instance around to these components
instead of just making the logging class static. If I make it static I
wouldn't need to
pass an instance around. What is your take on this?

Have you seen the Microsoft Enterprise ApplicationBlocks? There is a
logging block that should meet your needs. You might want to either
use this instead or model your component after it (the source code is
provided).

http://msdn2.microsoft.com/en-us/library/aa480464.aspx

 

[Guest]

I would recomend to use a Singleton class here.
This means a static GetInstance method which only instanciates the class
once and gives this instance back.

 

[Bruce Wood]

I would check out the Microsoft Enterprise Application Block first.

If it doesn't suit your needs, or you don't have time to study it,
then I would side with Martin: create a logging instance class, then
create a static method that returns a (singleton) instance of it. I
would also create a logging interface and have the static method
return that type.

The logic behind this is that you can then (if you want to) create
other logging classes that implement the same interface but log in
different ways, and swap them out with a minimum of fuss.

 

[Guest]

So in using a singleton I am going to call it directly like so,
singletonClass.Instance().method;
and with using a singleton I don't have to pass it around from class to
class, I can just call it as above, correct?

 

[Guest]

Hello,

A singleton method looks normaly like this.

private static MyClass instance = null;
public static MyClass GetInstance()
{
if(instance==null)
{
instance = new MyClass(); //Only done once
}
// You can do other stuff here
// For example calling some Init methods
return instance;
}

And will be called like this:
Your.Full.Namespace.MyClass myreferencetomyclass =
Your.Full.Namespace.MyClass.GetInstance();

Hop it helps!

All the best,

Martin

 

[Jon Skeet [C# MVP]]

A singleton method looks normaly like this.

private static MyClass instance = null;
public static MyClass GetInstance()
{
if(instance==null)
{
instance = new MyClass(); //Only done once
}
// You can do other stuff here
// For example calling some Init methods
return instance;
}

Except that's not thread-safe. It's simpler to use a static
initializer.

See http://pobox.com/~skeet/csharp/singleton.html

 

[Guest]

Good point for the concept!

But what I meant was alittle more custom specific.
For example if the sender is passed as a parameter, there would be the write
place to forward it to the accurate method.

All the best,

Martin

 

[Guest]

You wouldn't necessarily create one ref to singleton and pass it around to
the different classes. I figure I would get a ref to getInstance whenever I
would need it and destroy it after I am done using it in each class. Is that
how you guys would use it?

 

[Guest]

Hello,

Yes, you don't have to pass around it, cause every class can call the
GetInstance().
"destroy" as you sayed, is only a "null" set .

All the best,

Martin

 

[Guest]

Thank you all!

Hello,

Yes, you don't have to pass around it, cause every class can call the
GetInstance().
"destroy" as you sayed, is only a "null" set .

All the best,

Martin

 

[Bruce Wood]

Oh, and GetInstance() might be better implemented in C# as an Instance
property. I think it reads better:

Logger.Instance.Log(...);

versus

Logger.GetInstance().Log(...);

 

[Fernando Botelho]

Oh, and GetInstance() might be better implemented in C# as an Instance
property. I think it reads better:

Logger.Instance.Log(...);

versus

Logger.GetInstance().Log(...);






- Show quoted text -

Why don't you use a simple static method in a static class (if you are
using .NET Framework 2.0)?
I think the singleton instance, in this case, is completely useless.

Regards,
Fernando

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I would recomend to use a Singleton class here.
This means a static GetInstance method which only instanciates the class
once and gives this instance back.

Why singleton over a static class?

The only reason I can think of is if you want to be able to change the
logging tool under need, let's say from EventLog to a file.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I have a logging component that I will access in other assemblies. So it
was
brought up to me that I should pass an instance around to these components
instead of just making the logging class static. If I make it static I
wouldn't need to
pass an instance around. What is your take on this?

If you use it in different assemblies you will have to place it in a
separate assembly that all other projects will need to add a reference to.

Regarding your question, I have a similar situation, I decided to use a
static class and based on a flag I use either the EventLog or dump it to a
file.

Agreed, my environment is simple, if you have a dynamic environment you
should implement something more fancy like a Factory.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Its a pretty simple class that will send emails, write to eventlog or to a
file. My thinking is if I pass an instance around and it gets passed down
a
chain of about 3 classes then I will have multiple refs to my logging
class
and I am wondering if that is the proper coding technique to be using
here?

I will definetely will not pass an instance around. A logging class makes
sense to have it accesible from all over the app, I would select either a
static class or a Singleton

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Why don't you use a simple static method in a static class (if you are
using .NET Framework 2.0)?
I think the singleton instance, in this case, is completely useless.

Not really, if the logging facility change dynamically (file, eventlog,
email, SMS, etc) you will want a Factory that build the concrete class
according some parameters:

class Log
{
ILog current;
static public ILog GetLogger{ get{return current;}}
static Log()
{
switch ( flag)
{
case Email: current = new EmailLogger();break;
case Eventlog: current = new EL_Logger();break;
case textl: current = new FileLogger();break;
}
}
}
interface ILog{ void Log(......);}
class EmailLogger:ILog{}
.....

 

[Fernando Botelho]

Hi,









Not really, if the logging facility change dynamically (file, eventlog,
email, SMS, etc) you will want a Factory that build the concrete class
according some parameters:

class Log
{
ILog current;
static public ILog GetLogger{ get{return current;}}
static Log()
{
switch ( flag)
{
case Email: current = new EmailLogger();break;
case Eventlog: current = new EL_Logger();break;
case textl: current = new FileLogger();break;}
}
}

interface ILog{ void Log(......);}
class EmailLogger:ILog{}
....- Hide quoted text -

- Show quoted text -

Hi Ignacio,

..NET 2.0 have some facilities to work with logging, based on
configuration files (*.config's). You don't need to switch which
logging class use based on a flag passed from client classes.
Instead, .NET Framework 2.0 have classes (namespace
System.Diagnostics) that abstract this job for us. For more
information, take a look at http://msdn2.microsoft.com/en-us/library/system.diagnostics.aspx

What I want to say, is that your (static) class can abstract the BLC
methods to do this kind of job, instead of create instance class (the
unique advantage from this is that you can decide, based on an commom
interface, which class to use) and verify other things about log
source etc.

ps.: sorry by my poor english. my natural language is another one.