The best approach is based on the isolation of the UI from the other parts of the application. You don't want to state and restore the state directly. You need to have a separate
data model agnostic to your UI, but the data model should be exposed to UI. This way, you will create a
loose-coupling approach:
http://en.wikipedia.org/wiki/Loose_coupling[
^].
You UI should be able to populate from the model, modify the model or store modified data to the model. As to the persistence of the state, you should have persistence based on the model, not the UI.
The persistent mechanism should be
agnostic of the particular data schema (metadata), to be re-usable and reliable. To get such thing, you need to learn about
serialization:
http://en.wikipedia.org/wiki/Serialization#.NET_Framework[
^],
http://msdn.microsoft.com/en-us/library/ms233843.aspx[
^].
The good serialization code should be able to store/restore any arbitrary
object graph and be
non-intrusive to the data model. It means that the data model should be developed in a way agnostic to serialization mechanism.
The perfect tool for such thing is
Data Contract. Please see:
http://msdn.microsoft.com/en-us/library/ms733127.aspx[
^].
Please also see my past answers where I advocate this approach. You don't have to change anything in your data, you only add some .NET
attributes. Please see:
How can I utilize XML File streamwriter and reader in my form application?[
^],
Creating property files...[
^],
deseralize a json string array[
^].
See also:
http://en.wikipedia.org/wiki/Finite-state_machine[
^],
http://en.wikipedia.org/wiki/State_diagram[
^].
—SA
Submit an article or tip