Beyond MVC/MVVM: DRUM (Dynamic Reactive User interface Model)

This article describes the graphical features available in the Sinapse platform. The article makes a comparison of standard approach to build modern user interfaces and the approaches used in Sinapse Platform to help customers in their daily jobs.

From UI perspective, Sinapse platform supports:

  1. all of most recent graphic interface media: desktop, mobile, web applications;
  2. both 2D and 3D visualization output;
  3. single or multiple screen output on capable hardware.

Modern user interfaces mainly use MVC or the variant MVVM. These models gives to the designer the ability to isolate presentation layer from the business model; at the same time guarantees to work independently in the two main areas using the right resources: in the graphical presentation layer the best result can be obtained from artists which styles the UI, while in the backend the best results can be obtained from engineers.

Sinapse platform follows the same patterns to manage user interface but adds features which helps companies to reduce drastically the time needed to design, test and deploy a complete user interface.

To describe how Sinapse platform works I start comparing a standard MVC against Sinapse approach.

Looking to the following figure on the left you can see a standard model stack, on the right you can see the Sinapse model stack.

In both stack you can highlights many common areas. So the question is: where is the advantage of sinapse?

To describe the differences and advantages I start from the top of the stack.

View layer

View layer of Sinapse platform describes the layouts of UIs using technology agnostic structured description; designers arranges the layouts using mainly two kind of elements:

  • Preconfigured objects: they are well defined ready to use controls (checkbox, list, button, and so on). The following figure shows some of them:

  • Dynamic objects: they are controls defined dynamic beacuse are described using XAML with data binding on properties and commands. Below a simple example of the dynamic object editor:

Below the XAML code:

<UserControl xmlns=""
    <SolidColorBrush x:Key="myBrush" Color="Blue" />
  <GroupBox Header="Header">
      <StackPanel Orientation="Vertical">
        <TextBlock Width="100" Margin="10" Foreground="{StaticResource myBrush}" Text="First Name" />
        <TextBlock Width="100" Margin="10" Foreground="{StaticResource myBrush}" Text="Last Name" />
        <Button Content="{Binding ExampleString}" Command="{Binding ClickCommand}" />

The final result of Dynamic object on the UI can be seen in the following figure:

All UI components are arranged from the designer to obtain the right result in terms of user interface.

Our approach does not need any intermediate compilation, it follows a WYSIWYG approach mainly on the fly: all UI components can be added, updated, changed and removed while the UI is running. The interface shows immediately the changes using the most recent information available, the designer immediately see the results and can gives it to the end user. This is the first advantage.

ViewModel layer

Second layer is the view model. It connects view and model layer and converts the model information into data used from View layer to interact with the user.

View and viewmodel links together using a two way mechanism which allows to receives data and feeds back directly to the model. This intermediate layer is different from the standard one, the advanced features of sinapse gives to the designer multiple facility to define how links and converts data:

  • The most simple one use a graphical representation based on arrows: arrows connect source and destination defining a path for the data flows; when the source publish information to the destination the value is reported to the View layer; View layer can update the source on demand if requested; below a figure showing a simple connection arrow:

  • Another one adds, to the previous, an intermediate layer, like a code behind, which allows designers to use scripts to define the behavior of viewmodel; nothing new if I don’t write that scripts in viewmodel can be written on the fly while the UI works; this feature gives to the designer a great power because: reduce development cycle, see immediately what happens on UI using the real information coming from the source. At same time scripts can define direct data binding to interact with user interface. Below Sinapse editor with a script and a binding property for the View layer:

   This is an example code to use has a startup point for development

using Opc.Ua;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MASES.Sinapse.GuiObjects.AutoConfigurable.Basic
    public class XamlExample : SinapseAutoConfigurableBasicGuiObjectConfigurableContext
        /// <summary>
        /// Runs when a property change
        /// </summary>
        /// <param name="propertyName">The property changed</param>
        /// <param name="propertyValue">The associated value</param>
        /// <param name="timeStamp">The timestamp of change</param>
        /// <param name="statusCode">The associated <see cref="Opc.Ua.StatusCode"/></param>
        public override void PropertyChanged(string propertyName, object propertyValue, DateTime timeStamp, StatusCode statusCode)
            base.PropertyChanged(propertyName, propertyValue, timeStamp, statusCode);

            ExampleString = "new value";
        /// <summary>
        /// Called on initialization
        /// </summary>
        public override void Init()
            ExampleString = "Start value";

        string exampleString;
        public string ExampleString
            get { return exampleString; }
            set { exampleString = value; OnPropertyChanged("ExampleString"); }

To explain this simple script it is possible to highlight:

  • The public property ExampleString is the binding property used in the XAML of View layer to fill the content of the button, it is initialized to “Start value“;
  • The changes are captured from the PropertyChanged method: when something change PropertyChanged is called and the designer can do something. In this example when any property change ExampleString is updated to “new value“.

Model layer

The last element in the stack is the model. Sinapse Platform divides the model in two macro elements: the first and most simple runs into UI process, the second and more complex runs within the Sinapse server process, These two macro elements connects togheter with an high efficient transportation channel. The reason of the split will be more clear in another article where will be described the multipoint UI.

The macro element of the model within the UI process is the endpoint connector of the model with the ViewModel. I don’t explain nothing more because it is not important into this discussion.

The second macro element of the model lives within sinapse server; the model publish information using the concept of properties: properties are information containers, they had symbolic names and contains values like boolean, string, numeric, arrays, and so on. Viewmodel connects to the properties of the model and use them to give data to the view.

Model transportation channel is based on a publish-subscribe model. The modification on properties are transmitted to the UI client using an high efficient communication layer: only changes are transmitted to view model. UI (view/viewmodel) and model remains completely insulated.

What is the advantage of Sinapse approach for the model?

I identified mainly these advantages:

  1. Like any other components of sinapse the model can be managed on the fly. This gives to the designer the power to define, change, update the model itself in any moment reducing the impact on running UI and code life-cycle.
  2. The model publish information to the UI using sinapse communication layer: this gives to the model designer the full power to create an UI which is reactive on events. How this is possible? It can be more clear describing what happens behind the scene. The code on the server receives information from all sources, it elaborates this information using scripts and feeds the properties when it is necessary. The viewmodel, and consequentially the view, is driven by the event published from the model.

To summarize. In this article I explained some concepts and features of Sinapse UI stack which guarantees, at every level, to be modified in real-time, upgraded with minimum impact on running UI, driven by events. The company named it DRUM (Dynamic Reactive User interface Model). DRUM is the common approach for any kind of UI available in Sinapse platform:

  • Desktop application
  • Mobile device App
  • WebApp

Further article will go deeply into some concepts described in this article clarifying better the approach used in Sinapse platform.