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