locked
Encapsulating data access inside a static class. RRS feed

  • Question

  • Is there any downside to me creating a static class to encapsulate my app's data? In my app there is only one source of data - logically it's tied to the user's WiFi network and they can only be connected to one of these at any instant in time.

    This static class would be initialized (probably via an async operation) within the App.xaml.cs code at some appropriate place.

    The data will appear as a static collection class which is the root of a hierarchy.

    If I do this then the data class will be static and the methods/properties within it would be static too - would this have any negative impact on how the data is referenced within the XAML bindings?

    Thx

    Cap'n

    Wednesday, October 23, 2013 3:38 PM

Answers

  • Yes, there is a down side. Static properties can't raise INotifyPropertyChanged, so they're unable to broadcast their changes to your bindings. A singleton (such as App.Current) instead of a static class will be more appropriate.
    Wednesday, October 23, 2013 4:42 PM

All replies

  • What language and UI layer are you using so we can get you into the appropriate forum?

    edit: never mind. you mention a .cs file. I'll get this moved for you.

    --Rob


    Wednesday, October 23, 2013 3:41 PM
    Moderator
  • What language and UI layer are you using so we can get you into the appropriate forum?

    edit: never mind. you mention a .cs file. I'll get this moved for you.

    --Rob


    C# XAML

    Wednesday, October 23, 2013 3:49 PM
  • Yes, there is a down side. Static properties can't raise INotifyPropertyChanged, so they're unable to broadcast their changes to your bindings. A singleton (such as App.Current) instead of a static class will be more appropriate.
    Wednesday, October 23, 2013 4:42 PM