Push Domain Model Changes

Problem

When one user commits a transaction that updates the domain model on the server, how can a client application display these changes to a different user?

Context

You are developing a multi-user application that commits transactions on an application server. Changes to persistent data should be propagated to everyone viewing the data.

Forces

Solution

The client registers as an observer of specific model components and the server notifies observers when changes occur.

Resulting Context

Changes from other transactions can only be introduced at transaction boundaries, so the client developer needs to consider when it is appropriate to refresh its view based on the transaction model that has been chosen.

Updating a view could overwrite changes that are in progress by the end user. Therefore, it may be necessary to represent the user's changes independently of the view.

Rationale

Registering as an observer makes it easy for the client to identify when its view needs to be updated, because it receives a notification everytime this is necessary. In contrast to pulling domain model changes, there is no wasted processing time when no view updates are necessary.

If the application server allows for fine granularity of observing components, the observer only needs to update its view when the specific components of interest are updated. A potential disadvantage is that the client must register its interest in a number of components.

A disadvantage is that the client may waste time processing notifications when it is not willing to update its view. If notifications are expensive, e.g. when a server has many registered observers, the server may experience unnecessary delays by notifying observers who do not act on the notification.

Related Patterns