[2.0]More Create or more Persistance

[JPicasso]

We are in the middle of a design and are starting to split on a couple issues. I was hoping to get some input or maybe some articles that might address some of our confusion.

The main point is, is it better to instantiate and destroy objects, or keep them in memory for the life of the program (or a "long" time whatever that is) ?

One camp here argues that .Net takes care of all this objects creation and destruction, and so just do what you need, when you need to.

The other camp argues that it's better to instatiate once, and keep what you need "handy". Especially if these objects would require stuff like database access or file access on creation or implementation.

Any insight would be great.

[Kasracer]

The main point is, is it better to instantiate and destroy objects, or keep them in memory for the life of the program (or a "long" time whatever that is) ?

This completely depends on your object. Do you need it for the life of your program? If so, keep it. If not, destroy it.

It should become obvious what variables you need or don't need for the life of an application.

One camp here argues that .Net takes care of all this objects creation and destruction, and so just do what you need, when you need to.

I don't like this camp. The GarbageCollector does NOT clean up objects immediately. There is no guarentee that the garbage collector will even clean up objects until it wants to.

Any object that inherits the IDisposable interface should be palced inside of a using statement

using (StreamWriter fout = new StreamWriter("Dunno.txt")){
      //Code Goes Here
}

This way it will ensure that the StreamWriter is cleaned up immediately and it will ensure that the Stream is closed. If you just let .Net do everything for you, not only can you cause bugs that are almost impossible to debug, but it's poor programming.

The other camp argues that it's better to instatiate once, and keep what you need "handy". Especially if these objects would require stuff like database access or file access on creation or implementation.

Keep "handy"? You should know if you'll need something again later. If you do and it's more efficient to keep it around then keep it. Something like a database connection may not be a good idea to keep active the whole time though.

I'd say create the variable when you need it. You should avoid global variables anyway.

[mendhak]

This is .NET, not VB6.

Use your objects only when you need them, especially database objects. Bandwidth is not free, not even in internal environments.