Rendering Engine vs Forms on design time

  • Article

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:

  1. 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. 
  2. Typically the 'static' forms will be richer, or harder to generate.
  3. 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:

  1. 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.
  2. 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.
  3. The size of the binaries typically will be smaller.