Here's my setup:

  1. Entity Framework Backend
  2. Large WPF project that has a main window with 3-4 user controls on it, each of which has 3-4 user controls on it (and so on, in some cases)

What I currently have:

public class MySettings
   public string Property1 { get; set; }
   public string Property2 { get; set; }
   public string Property3 { get; set; }
   public string Property4 { get; set; }

public class FileService
    public void HandleFile();
    public event EventHandler FileChanged;

public class UserControl1
    MySettings settings;
    FileService fileService;

public class UserControl2
    MySettings settings;
    FileService fileService;

There are quite a few UserControls (or VMs) that need to know about the settings class. Here's an example of what happens:

  1. Application loads. User goes in to the "Settings Window".
  2. User changes settings.
  3. UserControl1 gets notified of a settings change, and adds a new user control
  4. UserControl2 gets notified of a settings change, and makes a stackpanel visible
  5. etc, etc, etc.

My dilemma:

How do I handle all user controls and windows having access to these classes? Specific questions:

  1. Should I create a main settings class in a top-level ViewModel and propagate this settings class through to a series of sub viewmodels?
  2. Should I create a static class to handle all of these?
  3. Should the FileService also be propagated down through each ViewModel? Is there a cleaner way to do Services while ensuring each control/window is using the same one?
  • 2
    You should have a look at Prism, it's build to solve those problems. – nvoigt Dec 5 '18 at 18:10

I think what is best depends on the project you like to have.

My case: I have a small app. There are some settings, no tests. Solution: Static class methods to ask and set. Example

public static boolean IShouldAskTheUserToOpenThePrivacyPolicy() {
        return !userHasReadThePrivacyPolicy;

used later like

if (Settings.IShouldAskTheUserToOpenThePrivacyPolicy()) askIfTheUserLikesToSeeThePrivacyPolicy()

I thought about

  • A static class as I have
  • A Singleton: I would always write Settings.instance()
  • Using different Settings objects/interfaces for different classes: These were good if I had tests.

Since Java would like me to introduce an Interface for each class' own settings, I rather go for the anti pattern of a fat class here, making the place for future contribution by other people obvious. If it were Python, I would still use the class and have tests.

How I propagate the changes: You can observe the settings. Objects can attach as an Observer (Pattern).

With the file service it is again your choice. I do not know what you want to do and what you face.

Language: If I rename Settings to UserPreferences, there it is clear, that there is only one user in the app. In a server application however, this must not be singleton/static class. With "FileService" it is of equal thought. "FileService" does not reveal anything about what it does or what needs it responds to in deed. So, I cannot tell you. If you answer to what it is the FileService does for whom? Then, probably you will not need to ask me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.