Separated Presentation:

Although the domain cannot call the presentation it's often necessary for the domain to notify the presentation if any changes occur. Observer is the usual solution to this problem. The domain fires an event which is observed the by presentation, the presentation then re-reads data from the domain as needed.

A good mental test to use to check you are using Separated Presentation is to imagine a completely different user interface. If you are writing a GUI imagine writing a command line interface for the same application. Ask yourself if anything would be duplicated between the GUI and command line presentation code - if it is then it's a good candidate for moving to the domain. [emph mine]

That's all well and good, but it seems to be reducing MVC (which is what I was reading about before I came to this page) to n-tier design (where n, surprisingly, is currently 2 -- which, when you're talking just GUI, I suppose is fine).

I'm pretty sure MVC is more convoluted than 3-tier design, which is what I usually use, but there I'm still reading.  Until then, this jive makes up a pretty good list of "best practices", especially the part I highlighted.  Being able to quickly remove from or add to your GUI without any change in data logic is the real test of [what I think is better called "encapsulation" -- why Fowler is re-monikering, I don't know] in your app's design.

Excellent, simplest case (give or take) logical refactoring of a non-tiered to properly tiered design follows the description on that page. Nearly required reading, kk?

Labels: , ,