Question

I have multiple business entities in VB.NET Windows Forms application. Right now they are instanced on application startup and used when needed. They hold descriptions of business entities and methods for storing and retrieving data. To cut the long story short, they are somewhat heavy objects to construct (they have some internal dictionaries and references to other objects) created and held in one big global variable called “BLogic”.

Should I refactor this so that each object is created when needed and released when out of scope? Then every event on UI will probably create a few of this objects.

Should I strive to minimize creation of new objects or to minimize number of static and global objects? Generally I am trying to minimize the scope of every variable but should I treat this business logic objects specially?

Answer 1

Let’s look at the two options you’ve presented:

Single Global Instances

Pros:

• Less performance cost in each method because the objects are already created
• No need to figure out how to pass the data around

Cons:

• Chance that objects are created but never used. This is a waste of both memory and performance. This could be mitigated by using lazy initialization that will create the object the first time it is used but still keeping a single globally created instance.
• Multithreading concerns such as ensuring data consistency (potential performance and development costs)

Unique per function instances

Pros:

• Each function gets it’s own copy and does not have to worry about what other functions may be doing at the same time.
• If the objects are not being constantly created and destroyed, you may have a lower total memory usage for your program.

Cons:

• Depending on how long it takes to create the object, you could have responsiveness issues in the UI.
• Depending on how the object is created, you may have to wait for another function to finish creating the object before you can create your copy.

This is not meant to be an exhaustive list, but it does point out the main tradeoffs as I can see them. Obviously, you know more about the situation and which tradeoffs are acceptable. A few judiciously chosen globals can be useful, but like most people I would lean away from having a lot of globals unless they represent something that there can only be one of, like a SerialPort, or something that the entire application should only have one of, like an ApplicationSettings class.

Don’t undervalue your time (both now and later when you come back for maintenance) as a cost. Sometimes a “better” solution may actually be worse because it takes too long to implement. Often “good enough” turns out to be, well, good enough.