Question

Globals are evil right? At least everything I read says so, because something might alter the state of the global at any point.

However, I’ve a DB object that’s a bit of a tramp in regards class parameters. The property below is an instance of a wrapper class that automatically works in MS Access or SQL – hence why it’s not EF or some other ORM.

Public Property db As New DBI.DBI(DBI.DBI.modeenum.access, String.Format("Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0} ;Persist Security Info=True;Jet OLEDB:Database Password=""lkjhgfds8928""", GetRpcd("c:\cms")))

The code itself does have PostSharp for exception handling, so I’m thinking that I can conditionally handle oledb errors by logging them and re initialising the DB if it is Null.

Up till now, the solution has been to continually pass the db around as a parameter to every single class that needs it. Most of the data classes have a shared observablecollection that is built from structures that individually implement inotifyproperty changed. One of these is asynchronously built. The collection property checks if it’s empty before firing off the private Async buildCollection sub.

Given that we don’t use dependency injection (yet) as I need to learn it; is the Global property all that bad? Db is needed everywhere that data is pulled in or saved. The only places I don’t need it at all is the View and its code behind.

It’s not a customer facing project but it does need to be solid.

Any advice gratefully recieved!!

Answer 1

Passing the DB connection as a parameter into your classes IS using dependency injection, perhaps you just didn’t recognize it as such. Hard coding the connection string in the callers is still code that is not free of dependencies, but at least your database accessors themselves are free of the dependency upon a global connection.

Globals aren’t just evil because they change without notice – that’s just one effect you see resulting from the bad design choice. They’re evil because a design using them is brittle. Code that depends upon globals requires invisible stuff to be set correctly before calling it, and that leads to inter-dependencies between unrelated code. The invisible stuff becomes critically important stuff. Reading just the interface of a module that internally uses globals, how would I know that I have to call the SetupGlobalThing() method before calling it? What happens if I call IncrementGlobalThing() and DecrementGlobalThing() and MultiplyGlobalThing() in varying orders, depending on the function the user selects?

Instead, prefer stateless methods where you pass in all the stuff to be changed and used: IncrementThing(Integer thing) doesn’t rely on hidden setup steps. It clearly does one thing: it increments the thing passed in.

It may help to think about it from a unit testing viewpoint. If you were to write a unit test to prove a specific module of code works, would you need to pass in a real database connection (hard*), or would you be able to pass in a fake database reference that meets your testing needs easily?

The best way to test your logic is to unit test it. The best way to test your class interfaces and method structure is to write unit tests that call them. If the class is hard to test, it’s likely due to dependencies upon external things (globals, singletons, databases, inappropriate member variables, etc.)

• The reason I called using a real database “hard” is that a unit test needs to be easy and fast to run. It shouldn’t rely on slow or breakable or complex external things. Think about unit testing your software on the bus, with no network connection. Think about how much work it is to create a dummy database: you have to add users, you have to have the right version of schema in it, it has to be installed, it has to be filled with the right kind of testing data, you need network connectivity to it, all those things can make your testing unreliable. Instead, in a unit test you pass in a mock database, which simply returns values that exercise your code being tested.