Why use serialisation/Deserialisation functions when we can directly do it using IsolatedStorageSettings.ApplicationSettings?

In Windows phone we can store and retrieve anything using

   IsolatedStorageSetting开发者_运维百科s.ApplicationSettings.Add("foo", bar);
   IsolatedStorageSettings.ApplicationSettings["foo"]

Then why people are using "sharpSerializer" kind of things ?

---

The settings is a flat organization with key/value pairs. For simple objects that's not a problem but if you have rich collections and don't want the overhead of deserializing a list just to get to an element, the settings can be problematic. They also require the element to be serializable, whereas using the isolated storage file system you can control the serialization and serialize anything. Furthermore, you can choose the serialization strategy such as binary, JSON, XML, or otherwise. Finally, there is a limit to how effectively settings will serialize objects. I'm not sure what it is because it's not published but more than one developer has told me larger objects or large amounts of objects start to behave erratically, throwing exceptions or not persisting correctly, in the settings.

PS - also, since you mentioned Windows Phone 7, there are limits to settings whereas the file system does not have a quota.

---

The big problem with storing the objects in the ApplicationSettings is that the entire contents of the settings are serialized and deserialized together.

As soon as you access just one setting, all settings a deserialized and loaded in the Dictionary<string, object> that backs the ApplicationSettings. Hence its not good choice to store large number of settings or to store large objects that require significant serialization.

---

Off the top of my head:

IsolatedStorageSettings are typically slower to access and save to than IsolatedStorage files.

You can't save null in Settings, but you could create your own serialized representation of this.

The use of directories can make working with a large number of files much easier than requiring a long or complicated naming convention for the key to an object in Settings.

In some cases you may want to refer to an object stored in IsolatedStorage. You can't do this if it's saved in settings.

I suspect that objects added to Settings are still serialised in some way (in the background) - my guess would be binary serialization - as they need to be persisted to disk. By defining your own serializiaton you can be sure that this will work correctly/as expected. If you just rely on the system to do it you could end up with unexpected behaviour. If you have your own serialization you also have some guarantees on future and cross platform compatibility. (If that's a concern.)

---

Another important point that other didn't mention was that when you update your application by submitting a newer version to the marketplace, the entire ApplicationSettings get wiped off, as it is assumed that the new application will have its own defaults set. So it is always a good idea to serialize data in to the IsolatedStorage and not cram the AppSettings.