Monday, 23 December 2002
How do a GUI layer and a business object layer communicate?


A popular possibility is to define a view, with tailormade data. The logic is That nicely keeps the GUI layer independent of the object layer.

Well, yes, nice thought, but...

  1. It is a bit old fashioned, looks like the data flow from decades ago between batch jobs.
  2. The object layer has the duty to deliver.
    When the information scope of the GUI layer changes, changes are needed in the GUI layer itself, the view definition as well as the business object layer. That is a triple update. The desired independence is nowhere near.
  3. There is a danger that the programmer of the object layer can't avoid to
    • play safe and make the view over complete,
    • fill it with redundant information,
    • and accept the negative effects on performance.


A much simpler solution: plain methods, direct from GUI to object layer. The object layer can go and search for information, but only when and if needed.
  1. It nicely uses modern Object Orientation. A simple method call can have a complex implementation, but that remains hidden to the GUI layer.
  2. The GUI layer has a duty to ask. That is not too bad, as the GUI itself knows best what the GUI needs.
  3. The object layer does not care where a question is coming from. There is a good chance that a method already exists, can be reused, without the object layer or called methods need to change.
Yes, well, so how about the independence of the layers? What happens when the class tree changes? Or the method definition? No reason to panic. Encapsulation will hide most changes for the GUI layer. As long as the contract between GUI layer and OO layer remains the same, the backstage implementation can change radically.

Only for a heavy change, with impact on the class tree or method definitions, the GUI layer has to change The direct connection between GUI layer and objects quickly highlights which screens need an upgrade. Some screens simply seize to work at all. That is not a problem, just work:

  1. Create new classes with new attributes definitions,
  2. Define methods at the right place,
  3. Adapt the GUI layer.
    The list of broken screens is a clear "to-do-list" for the programmers. Just call the right method to the right class and ready, usually an update of just a few minutes.
Till next week,

With special thanks to Theo Maas and Antoinette Coetzee for their inspiring views and discussions.