Everything is possible. However, I strongly recommend not to serialize UI controls.
UI can be a temporary item of a software project. If you serialize UI, you won't be able to upgrade it in a backup-compatible manner. It's very likely that later on you will need to migrate to a different UI library or a whole platform. You database, busyness logic and other application specific code will survive… in you refrain from creation of hard coupling of UI with data model.
What you need is
loose coupling, see
http://en.wikipedia.org/wiki/Loose_coupling[
^].
Instead of serializing the UI, create a logical data model of you UI. It will be tightly bound to your functionality and not to UI elements. The model should be composed of pure data classes/structures. The relationship between data model and UI will be reduced to two operations: data to UI (population) and UI to data (acquisition). Yes, this is extra work, but it will pay very well of in near future.
Serialization of such model won't be a problem. I suggest you don't do it manually. My best advice is using
Data Contract, see
http://msdn.microsoft.com/en-us/library/ms733127.aspx[
^].
This method of serialization is the most non-intrusive. You don't have to modify any of your types to make them serializable with
System.Runtime.Serialization.DataContractSerializer
or
System.Runtime.Serialization.Json.DataContractJsonSerializer
; instead, you only add attribute to your types and members.
As your thinking about UI serialization shows pretty good confusion about application architecture, I would advice to familiarize yourself with the
architectural patterns I listed in my past solution:
how to control Controlls of a user interface form through Functions (methods)[
^].
Here is the explanation of architectural patterns in general:
http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)[
^].
You don't have to learn them, but you really need to get a good idea on how robust application architecture should be build.
—SA