In the Avalon programming model, the framework does a lot of work to implicitly wire up things which would require explicit coding in other (i.e. WinForms) paradigms. Routed Events is a great example of this. It’s quite a paradigm shift but once you get your head around it you’ll see the point.

The key concept is that events (well, “Routed” events) are implicitly passed up / down through the containment hierarchy. The way this works is that first, an analagous “PreviewXXX” event is “Tunnelled” down from the top (root) of the hierarchy to the target object. Then, the “XXX” event is “Bubbled” up from the target object to the root.

Take the following setup as an example:

+==Form1================+
+                       +
+   +--Panel1---+       +
+   +           +       +
+   + [Button1] +       +
+   +           +       +
+   + [Button2] +       +
+   +           +       +
+   +-----------+       +
+                       +
+==Form1 ================+

Let’s say the user clicks on [Button1]. This would result in the following sequence:
//”Tunnel” down to target
1. Form1–>PreviewMouseDown
2. Panel1–>PreviewMouseDown
3. Button1–>PreviewMouseDown
// “Bubble” up from source
4. Button1–>MouseDown, source=Button1
5. Panel1–>MouseDown, source=Button1
6. Form1–>MouseDown, source=Button1

For more details check out Avalon - Routed Events Overview.

Basically, this looks much more like a Pub/Sub message bus than a Model-View-Controller architecture — ie. more loosely coupled message passing and less tightly coupled state synchronizing. On the whole this sounds like a Good Thing; I haven’t got enough experience with Avalon yet to know if it will yield real improvements in architecture.