locked
Approach for handling global application object RRS feed

  • Question

  • Hi all,

    What is the recommended way in VS.NET to have a global application handler object?  Something that can load/verify/return user folders, settings, application specfic settings, manage the unhandled exceptions, etc.  I would have a class that has most of the code, then subclass it for each application. 

    I can create one if I start as a module instead of a form.  But then I lose some options such as NetworkAvailabilityChanged, etc. 
    Can I define a "Public" object from within a form (I don't think so and don't feel this would be the right approach.)?
    Or can I "attach" an object to an existing global object store (such as "My."), etc.?

    Once created, any object in my application should be able to reference methods/properties of this application object to get default folders, user values, etc. as necessary. 

    And what is the recommended approach to manage this.

    Your suggestions are appreciated...

    FletcherJ
    • Edited by FletcherJ Monday, June 15, 2009 6:26 PM
    Monday, June 15, 2009 6:24 PM

Answers

All replies

  • Well, my preferred way of handling global classes such as this is via a Singleton pattern.  In VB.NET it would looks something like:

    Class MySingleton
        Private Shared _instance As New MySingleton
    
        ' Prevent instantiation outside of the class
        Private Sub New()
        End Sub
     
        '
        ' Here are your public properties and Methods
        '
    
        ' Here's how you get a hold of the single instance
        Public Shared ReadOnly Property Instance
            Get
                  Return _instance
            End Get
        End Property
    End Class
    
    

    I would probably do something like this in a module to hide the access via the instance property:

    Module Globals
       Public MyAppObject As MySingleton = MySingleton.Instance
    End Module
    Then you could simply say:

    MyAppObject.SomeMethod()
    Pretty much anywhere you want...

    I'm not sure why though the module didnt' work for you - you can handle events in a module as well?  I prefer the singleton method, mostly because modules tend to pollute the global namespace....

    HTH


    Tom Shelton
    Tuesday, June 16, 2009 4:48 AM
  • It is not recommended to have global application handlers or whatever, but if you want it: you can starting with version VB1 use modules, in that is nothing changed
    (The exteniton is now vb instead of bas).
    Success
    Cor
    Tuesday, June 16, 2009 4:50 AM
  • Cor,

    Given your statement about what is recommended, then what is recommended?

    I need a way from anywhere in my code to determine things like:

    - Where the data for this application is stored (obtained from some source on startup)
    - Reference to user object (created at startup)
    - System wide values such as contact information for tech support, etc.
    - Encrypted information on external services (SQL server, etc.) - which is very critical as this changes frequently

    Some of this data is stored in a file that is referenced during startup that our IT folks can go in to update - especially when the fine SQL folk change where the server is located, require us to update the password used by the application to get data, move the folder that holds public shared (non SQL) data to a new server, etc.

    I use my.settings to track user specific preferences, but this won't (apparently) work for application specific data that is shared for all users and IT wants to manage from a single source.

    If there is a more appropriate way to do this, I would like to know.

    Thank you,

    FletcherJ

    • Edited by FletcherJ Wednesday, June 17, 2009 4:52 PM
    Wednesday, June 17, 2009 4:46 PM
  • Tom,

    Thanks for the info on the Singleton approach.  And yes, I can use the module approach.  But I am trying to avoid it because, when I do so, VS.NET refuses to allow me to do some things that are nice otherwise (see my initial message re NetworkAvailabilityChanged).

    But I could use the singleton approach to only create the object once, even though it appears that it is being created in each form, so this would be a good solution even without using the module approach.

    Thanks,

    FletcherJ
    Wednesday, June 17, 2009 4:49 PM
  • Hi,

    Not sure if this is what your looking for but perhaps you want to create a custom section in the applications configuration file.

    http://support.microsoft.com/default.aspx/kb/313405

    http://msdn.microsoft.com/en-us/library/2tw134k3.aspx

    There is more information out there if you search for it.

    Basically all your 'data' would be stored in the app.config file. They could change without needing to recompile the application.

    Another option for you to look at. Hope it's what you need.


    www.dsmyth.net | www.dsmyth.net/wiki
    • Marked as answer by Xingwei Hu Monday, June 22, 2009 5:23 AM
    Wednesday, June 17, 2009 6:50 PM
  • Derek,

    Using the configuration file will help, but I still need a way to have logic available as well.  My singleton approach works fairly well and I can use the configuration file as well.  Now the only issue I have is creating some common objects that can be used across applications - but I have most fo these details worked out as well.

    Thanks again,

    FletcherJ
    Wednesday, June 24, 2009 7:06 PM