Posts tagged MVVM

For the last few days I was mainly pair-programming (pair-refactoring to be honest) some Silverlight UI code. I must confess I really rarely write UI code these days. Actually, I don’t remember the last time I’ve written a ASP.NET control from scratch. I did write some UI for DDDSample.Net but it was not production code after all.

MVVM

When I bumped into this Model-View-View Model (MVVM) stuff, I was a little confused. Then came the moment of enlightenment. I realized I saw all of this in totally different context – in loosely coupled system architecture. Look at this:

The blue elements on the right is MVVM stuff. It contains of three classic MVVM components and an additional one — an Event Aggregator. It is used for communication between MVVM triads. Application is organized in such a way, that multiple MVVM triads form vertical slices of functionality. These slices are loosely coupled so that they can be changed independently. Actually, when you value loose coupling much, you should avoid any code sharing between slices.

The orange elements are the building blocks of DDD-based distributed application. It receives commands via Services, then it processes them in a Domain Model which is backed by a Data Store. Finally, state changes are communicated to the outside world via a Message Bus.

How do slices communicate?

They use events and (rarely) messages. The name I chose for the diagram, the Event Aggregator, is a little bit misleading, because ViewModels should be able to both publish an event (broadcast to all interested receivers) and send direct message to a concrete receiver. The only shared thing between slices is the definition of messages (sounds like SOA, isn’t it?).

Again, how does it relate to system architecture?

I think the picture says it all. View is an analog of Service interface. View Model is an analog of Domain Model. In fact, one can say that View Model is the Domain Model in the context of user interface as it models the domain of particular UI case. The model is the place where all the information lives, a Data Store if you prefer. Finally, the Event Aggregator (with mentioned earlier unicast capabilities) is an analog of a Message Bus (such as NServiceBus).

How does it work?

Let’s look at the example. There are two slices, A and B. For the purpose of the example, let A be master view (a data grid and search) and B — a details view.

User selects the row on a grid. In response to that View A to generate a command and passes it (by means of data binding) to the View Model A. The View Model validates command, processes it (updates all required properties) and, as a result, it publishes an event “SelectionChanged”.

The Event Aggregator receives the event and searches for its subscribes. It finds View Model B so it forwards the event to it. During processing of event, View Model B requests all the data it needs from the Model B and updates its own properties using retrieved values. View B is automatically updates as it is data-bound to its View Model.

Summary

As you can see, good architected applications tend to have fractal structure. Similar forms can be discovered on various levels of detail. I value such architectures very high. The coherence makes them simple and elegant.

One more thing in case you didn’t noticed. There is a trend recently to focus architecture discussion not on what’s horizontal, but on what’s vertical. As we are (hopefully and at last) moving away from waterfallish processes, we start building applications slice by slice, not layer by layer. These slices do have to have some architecture but not as much design up front. The layers are much less important. I don’t even care if all the slices have the same layers — it can be impractical. What I want to have is the conscious process of choosing the layers of each slice so it can be implemented in the simplest possible way.