silverlight windows phone 7 using static class for storing data

I am trying to write a tasks application for Windows Phone 7开发者_如何学C. Is it bad practice to store all the data in a static/singleton class? If so, what are my options? Thanks.

No, its not bad practice.

Doing it that way keeps all the settings in one place for easy persistence.

use can create static class and use can use it in application so that achieving Persistence is easy and other option for implementing are

Option 1:

public static void SaveNote(string content)
        {
                var fileName = "myNotes.dat";
                using (var store = IsolatedStorageFile.GetUserStoreForApplication())
            {
                if (!store.FileExists(fileName))
                {
                    using (var writeStream = new IsolatedStorageFileStream(fileName, FileMode.Create, store))
                    {
                        using (var writer = new StreamWriter(writeStream))
                        {
                            writer.Write(content);
                        }
                    }
                }
                }
            }

        public static string LoadNote()
        {
            var fileName = "myNotes.dat";
            try
            {

                using (var store = IsolatedStorageFile.GetUserStoreForApplication())
                {
                    if (store.FileExists(fileName))
                    {
                        using (var readStream = new IsolatedStorageFileStream(fileName, FileMode.Open, store))
                        using (var reader = new StreamReader(readStream))
                        {
                            return reader.ReadToEnd();
                        }
                    }
                }
            }
            catch (IsolatedStorageException e)
            {

            }
                return String.Empty;
        }

Option 2:

var note = IsolatedStorageSettings.ApplicationSettings;
           note.Add("Note", txtNote.Text);

It'd be better to not force a class to be a singleton by design, but rather be a singleton by usage. Have your Data Access Object (DAO) be a regular class. Implement a Service Locator that acts as an object registry, and let that be the class that maintains the singularity of the DAO.

Code example:

public interface INotesDao {
    void Save (string s);
    String Load ();
}

public class NotesDaoImpl : INotesDao {
    // etc.
}

public interface IServiceLocator {
    public TIntfc GetImpl<TIntfc> () {
        return Activator.CreateInstance (m_Mapping[typeof(TIntfc)]);
    }
}

public static class ServiceLocator {
    public static IServiceLocator Instance { get; set; }
}

// this isn't a robust implementation, just meant to get the point across
public class MyAppServiceLocatorImpl : IServiceLocator {

    private Dictionary<Type,Type> m_Mapping = new Dictionary<Type,Type> ();
    private Dictionary<Type,Object> m_Cache = new Dictionary<Type,Object> ();

    public MyServiceLocatorImpl () {
        AddMapping<INotesDao, NotesDaoImpl> ();
    }

    private void AddMapping<TIntfc, TImpl> () {
        m_Mapping[typeof(TIntfc)] = typeof(TImpl);
    }

    public TIntfc GetImpl<TIntfc> () {
        var implType = m_Mapping[typeof(TIntfc)];
        if (!m_Cache.ContainsKey (implType))
            m_Cache[implType] = Activator.CreateInstance (implType);
        return m_Cache[implType];
    }
}

public class MyApp {
    public MyApp () {
        ServiceLocator.Instance = new MyAppServiceLocatorImpl ();

        var dao = ServiceLocator.Instance.GetImpl<INotesDao> ();
        var notes = dao.Load ();
        // etc
    }
}

The reason to implement this is that singleton-by-design classes are harder to test properly, not to mention that it makes the classes slightly more complicated. Best to have them be dumb classes and let another class specifically manage singularity for all types of classes.