by Jose Mojica
Anyway, I've been learning a lot about WinForms architecture working on this project, so I thought about sharing some of the things I've learned in various posts.
The first thing I'd like to share is that I believe the main problem with WinForms is Control serialization. Control serialization is the root of all evil in WinForms.
Controls serialize to CodeDom. They don't serialize well to other forms, such as XML. Yes, you can write your own XmlSerializer friendly classes but let's face it, the serialization form they speak natively is CodeDom. CodeDom in principle is good because it is language agnostic. It is an abstract serialization format. The problem is that CodeDom turns into code. Code is not a good storage format because it cannot be easily parsed. And to make things worse, although Microsoft provides a nice way to turn CodeDom into code, they don't provide a way to turn code back into CodeDom. For turning code back into CodeDom you have to find a code parser. (We have played around with several and I'll post my findings later.) The only implementation of a class that returns CodeDom from code is in Microsoft.VisualStudio.Dll. It is not part of the framework's core assemblies. The framework's designer can turn the state of an object into CodeDom (after implementing four or five interfaces) but in order to load the code result back into the designer you need to provide it with CodeDom back.
I know there aren't too many people trying to write their own designers but I suspect there are a lot of people trying to save the state of their forms, and CodeDom would be perfect if you could take the resulting code and turn it back into CodeDom easily.
Is anyone else trying to turn code into CodeDom?