I went back and forth on this a lot when we were working on the design of our framework. Here are a couple of things to keep in mind:

1. Public variables are generally considered bad practice in OOP, therefore, in theory, the fewer the better.

2. Having a global application object that provides a wide variety of services does not limit your testing any more than using several different global objects. There's really no difference if your code checks for oApp.oSecurity vs. just oSecurity. In reality, the application object can actually enhance this because if you wanted to you could have objects like oSecurity, oFormMgr, etc. created on demand via access methods.

3. If you reference a hard coded variable name throughout your application code it will be a lot harder to change down the road later. You might want to consider making these items protected members of your application object and then when you want to interact with one of them, call a method that returns an object reference back. If you take this route all of your access to these objects is handled with one clean interface and if how that object is created changes you only need to change one place. IOW, GetFormManager could be RETURN This.oForms or it could be RETURN oForms if you later decided to move it to a variable. (This also helps to enforce encapsulation.)

4. The GetMethod approach I've described above also provides more flexibility because it can also use on demand instantiation or if the situation dictates it, it can actually make decisions regarding which object is returned. With a public variable object the only time you can really control the class is at instantiation time.