GarbageCollector, Dispose or static Methods?

I developed a few classes last month. They grow big (round 30-40 Methods each class).

I never take a thought of Memory Leaks, GarbageColletor or something like this (I must say this is my first own big project).

Now I have classes with Methods, 15 Classes Round About, each class min. 20 methods. 50% are Linq-Classes in the DAL, 50% BusinessClasses with BusinessLogic. NO Class uses global variab开发者_如何转开发les (no need), so theoretically I can make them static classes + methods. At the moment they aren't, I initialize a class object and use the class - and not disposing it.

Where I should start when I be angry of having Memory Leaks etc. when the system runs by ~100 users?

Don't worry about the methods of your classes since they do not consume memory: each method exists only once, in the class definition. What really takes memory is the data contained in the objects in the form of fields.

About disposing objects (I assume .NET here), it is not necessary unless you use unmanaged resources. The garbage collector will take care of freeing all the managed resources (that is, plain objects with their data) when necessary.

If you want more information about the .NET garbage collector and how to deal with memory leaks, you can for example look here: http://www.codeproject.com/KB/dotnet/Memory_Leak_Detection.aspx. But if you are at the start of your project, I would concentrate on getting a clear and maintainable design, rather than on memory management issues.

Whether you can make a class static does not depend on the use of 'global' variables but on the fact if a class uses instance fields (class member variables). If your methods do not use instance data the can be static (and there is a light preference to do so). If all methods are static you can make the class static as well.