Global Data Really that bad?

Question

I have an WPF mvvm application which handles shipment data, this includes breaking it down into Projects and proformas etc.

However, what i'm now faced with, is needing to know in a multitude of viewmodels, which project is currently selected, which proforma and so on, as well as having access to the lists of data such as Projects that have been pulled from the DB.

Now this data is loaded, updated, deleted and Inserted via classes i have called repository's. such as ProjectRepository, my plan was to store the loaded data in these classes as well, so it would contain a List (where project is my model) which would be publically accessible, and these Repository's are static.

So the problem comes down to this, Proformas are loaded based on the currently selected Project (via projectID from the DB) so the repository needs to know which Project is selected. My current system uses custom events which viewmodels subscribe too in ordered to capture a change in the project selection, however it seems a little ridiculous to me that i now dozens of events, each with dozens of subscribers, and frankly it makes it quite difficult to follow the code.

So, sorry for the huge chunk of text, I wanted to make it clear what my situation is, and ask the question that i know seems to anger some people. What is wrong with having a static class which simply holds properties for all the currently selected Object (project, proforma, shipment etc), this would make my life significantly easier.

Or is there a "right" way of doing this that I've not seen yet?

Answer 1

I think that, if you're tempted to use global static objects for mutable data, it usually points to a design flaw.

The central problem with using global variables is that you lose all encapsulation. This means that, as your application grows in size, it becomes impossible to think about (or test) parts of your program as components. Every instance of every component is potentially interacting with every other one, mediated by the global static objects. The problem is compounded once you add threading and concurrency to the mix.

My current system uses custom events which viewmodels subscribe to in order to capture a change in the project selection, however it seems a little ridiculous to me that i now have dozens of events, each with dozens of subscribers, and frankly it makes it quite difficult to follow the code.

I'm not convinced that this will make your life easier, even in the short term. Don't the view models need to get notified when the project changes? Otherwise, they are potentially displaying or acting on stale data. It sounds to me (admittedly based on limited info) that you should try and simplify the chain of events that occurs when the user changes projects.

Maybe you could just throw out the views and recreate them? Or maybe add a virtual method to your base view model like "OnProjectChanged"? Or maybe, if the view models actually don't need to get notified of the change, just pass them a Func<ProjectData> so that they can lazily pull the current data when needed. I don't know what would be best, but there has to be a better solution than introducing global statics and taking on all the headaches those entail.