Separate UI from logic

One of the most basic principles in design is to separate the UI from the logic. I'm not going to discuss a whole lot of reasons for that. Let's just summarize it as a matter of separation of concerns.

What I'd like to write in this blog post is that there are "new" reasons every now and then for why this principle is a good idea to follow. Some examples:
  • I listened to the .NET Rocks show the other day when Miguel de Icaza, one of the main guys behind Mono, was the guest. (Mono is an open source implementation of the .NET Framework, which runs on Linux and MacOS. And Windows.) He said on the show that if the funds for your project were there, he recommended writing three versions of the presentation for applications. One in Cocoa# for Mac, one in Gtk# for Linux and one in WinForms for Windows. Then each presentation version would gain as much as possible from each of the execution platforms (as opposed to other common approaches for multi-platform client UIs). The model (or engine as he called it) could be implemented once. (Nope, I'm not going to go on again about how I like the Domain Model pattern [PoEAA] for many situations and that I think that's what Miguel was thinking about...)

  • Perhaps the Tablet PC is taking off really soon. If you want your app to be really nice on that device, you should obviously build the UI specifically for the tablet.

  • The Compact Framework might also really take off, perhaps not with Pocket PCs as much as with cell phones. Anyway, this might mean that you might want to factor out the UI as much as possible from the model.

  • As I understand it, XAML (the upcoming way of building UIs in Longhorn) is very much about separating the presentation from the logic.