Rendering Engine vs Forms on design time
A couple of weeks ago I had an interesting design discussion about developing a smart client. This application is being developed with Windows Forms and is going to have more than a thousand forms. The center of the discussion was about creating the forms on design time -we can call it 'static' forms solution-, or creating a kind of rendering engine in order to paint the form on execution time - the 'dynamic' one-.
I advocated for the option of developing them in design time, but is true that in the last two or three years I have seen some apps -most of them were Java apps- designed with the rendering engine. My arguments were:
- We have a great tool for creating forms, VS.NET, that I don't want try to simulate or generate the data describing the form. I mean with the 'dynamic' forms we will need to create the rendering engine for run-time, but also a design tool, for the design-time.
- Typically the 'static' forms will be richer, or harder to generate.
- The information needed in run-time about the layout of each form will make the 'dynamic' solution slower -we have 64 Kb lines with some branches-. This point can be improved caching that data.
I see three advantages on the 'dynamic' solution:
- Easier to deploy a new form or a updated one, but is something that can be improved on the 'static' solution with a solution based on the updater application block.
- Seems to be easier to manage a high number of forms, be anyway is something to be developed. Also seems possible to improved this on the 'static' solution.
- The size of the binaries typically will be smaller.