MVVM- How would I go about propagating settings between my main view-model (and other view-models) and my settings dialog?

I am building a settings dialog for my application and right now all of the settings correspond with settings on the main v开发者_C百科iew-model, but as I add more view's and view-models some may not.

I need to know what the best practice is for loading the current settings into the settings dialog and then saving the settings to thier corresponding view-models if the user clicks okay.

I will not be using the Properties.Settings.Default system to store settings since I want my application to be as portable as possible and this would store user scoped settings in the directory: C:\Users\ username \Local Settings\Application Data\ ApplicationName Instead of in my application's directory.

In case it makes any difference I am using the MVVM Light Toolkit by Laurent Bugnion.

How about implementing that with the Messenger of the toolkit?

When changes are made in the Settings ViewModel you just inform anyone interested:

Messenger.Send<Settings>(changedSettings);

And all Viewmodels which need to know if settings have been changed register to that message:

Messenger.Register<Settings>(this, delegate(Settings changedSettings){loadSettings(changedSettings);});

Have a read here: Mvvm light messenger or check this similar post mvvm-light-how-to-access-property-in-other-view-model

You could use MEF, exporting a settings view from each view model and importing them as a list of views that you add to a stack panel or some such in your main settings view.

A good source of info of using MEF is: http://mef.codeplex.com/wikipage?title=Guide

Here is a sample program I meant to get up sooner:

using System; using System.Collections.Generic; using System.ComponentModel.Composition; using System.ComponentModel.Composition.Hosting; using System.Reflection;

namespace zTestConsole
{
    public interface ISimple
    {
        string Message { get; }
    }

    [Export("SimpleHello",typeof(ISimple))]
    public class SimpleHello : ISimple
    {
        [Export("Message")]
        public string Message
        {
            get { return "Silverlight rocks!"; }
        }
    }

    [Export("SimpleBello",typeof(ISimple))]
    public class SimpleBello : ISimple
    {
        [Export("Message")]
        public string Message
        {
            get { return "C# rocks!"; }
        }
    }

    public class SimpleMultiCat
    {
        [ImportMany("Message")]
        public IEnumerable<string> Messages { get; set; }
    }

    public class SimpleCat
    {
        [Import("SimpleHello")]
        public ISimple simple { get; set; }
    }

    class Program
    {
        private static CompositionContainer container;

        static void Main(string[] args)
        {

            AggregateCatalog catalog = new AggregateCatalog();
            catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

            SimpleMultiCat cats = new SimpleMultiCat();
            SimpleCat cat = new SimpleCat();

            Program.container = new CompositionContainer(catalog);

            try
            {
                Program.container.ComposeParts(cats);

                foreach (string message in cats.Messages)
                {
                    Console.WriteLine(message);
                }
            }
            catch (CompositionException ex)
            {
                Console.WriteLine(ex.ToString());
            }

            Console.WriteLine();

            try
            {
                container.ComposeParts(cat);
                Console.WriteLine(cat.simple.Message);
            }
            catch (CompositionException ex)
            {
                Console.WriteLine(ex.ToString());
            }

        }
    }
}

I've had this problem also. Solution for me was to have something like an ISettingsService Model. There would be 2 implementations. One for the real service and one mocked that was used for design time and unit testing.

An example here: http://compiledexperience.com/blog/posts/Blendable-MVVM-Dependency-Injection-and-Unit-Testing