Reactive Programming for .NET Developers

Once upon a time, programming languages where extremely different from the ones we have today.

The first-generation programming language was the machine-code one. It was made against the hardware itself, and for most, programming in such way meant creating hardware solutions like moving jumpers or switches or adding/removing cables.

The second generation of programming languages was the assembly language (such as Assembler). The name was related to the assembling stage of these languages into a machine level one that is able to run in the CPU execution pipelines. This language generation was the first made with text, although it was tightly coupled with hardware architectures.

The third generation of programming languages started the age of English-like languages that were able to run on top of hardware specifications with their own instruction set, no longer coupled with the lower hardware level. It started the reusability era.

These languages were not made in real CPU executable code. Programmers did their job in a high-level programming language that, after the compilation stage, translated into a lower-level one that was able to run into the CPU execution pipeline. At the beginning of the high-level programming era, the most diffused languages where IBM ® Fortran and COBOL.

Modern languages, such as .NET, Java, and C/C++, are all of the same generation as their grandparents of the 1950s. Obviously, the current languages have improved features and abilities, because of the long evolution time.

The main differentiation between the previous programming languages and the current ones is the programming paradigm—something like a programming approach of structured methodology that changes the way a programmer creates software.

The oldest one is the imperative  programming paradigm. It is made of a direct sequence of steps, usually numbered from 1 to N, that simply executes in a forward-only fashion. In these stages, the ability to jump forward or backward with commands, such as GoTo, was definitely a killing feature, while now, with modern programming paradigms, it is absolutely avoided. By programming with such an approach, a simple application made to sum two values was a simple sequence of steps, or instructions, that altogether achieved the desired goal. Here is an example in C#:

Console.WriteLine("Step counter: RUNNING"); 
 
Console.WriteLine("Write the starting value"); 
var startingValue = int.Parse(Console.ReadLine()); 
 
//value entering starting point 
REPEAT: 
Console.WriteLine("Write the ending value"); 
var endingValue = int.Parse(Console.ReadLine()); 
 
if (endingValue <= startingValue) 
{ 
    Console.WriteLine("ending value must be greater than starting value"); 
    goto REPEAT; 
} 
 
//this counter represents the distance between startingValue and endingValue 
var counter = 0; 
 
//increments the counter until needed to reach the endingValue 
COUNT: 
if (endingValue > ++counter + startingValue) 
    goto COUNT; 
 
Console.WriteLine("You need {0} steps to reach {1} from {2}", counter, endingValue, startingValue); 
Console.WriteLine("END"); 

As you can see in the preceding example, the whole program is only a list of steps where the current actor is at once the computer asking for something on the console and the user writing some response on the console. The program is unable to do multiple things together. Either the computer places a question to the user, or the user enters a digit or something on the keyboard to give the computer a command or some data.

There are no interaction constructs (for, for...each) available in imperative programming, and there is no code factorization into subroutines able to abstract and make reusable single portions of code.

The check logic against the user value is available through a simple GoTo statement that is able to move the control's flow pointer (the actual execution row) to a newly desired position. Regarding this check logic, the execution flow simply goes back to some previous line executing and entering a destination value.

Similarly, when it is time to count the distance between the two given values, the logic again uses the GoTo statement, changing the current state of the counter variable to the updated value. It is the last time the variable will contain the required result.

In imperative programming languages, such as Fortran, Pascal, or COBOL, there was a number for each row to give developers the ability to create interactive constructs, such as recurring jobs or any other interaction logic, by jumping between rows.

Obviously, this choice is not available in modern general-purpose languages, such as C#, which give the same feature with the use of a label (in the preceding example, we used Repeat and Count) instead of the row number. The result is the same.

To understand imperative programming, we must understand the meaning of the state. An application's state is the sum of all the data usually available within the code through fields, properties, and variables. When we started the preceding code, the application state was empty (we will ignore the Common Language Runtime (CLR) stuff that is in the memory together with our data). During the execution, some variables (startingValue and endingValue) became available by asking data from the user.

Later, a counter variable will make the most of the work to find the distance between the two numbers. What is the heart of the imperative programming paradigm is the status change that the code makes against available variables. As visible, the counter variable becomes incremented until the wanted value is found.

This status change still happens in other paradigms such as procedural-programming or object-oriented programming, although these paradigms bring to a higher level abstraction of data structures or a better code reusability.

Changing the application state is not something wrong by itself, but there are different programming approaches that may produce better results and together give the developer a more pleasant working experience. A typical use case happens when we deal with in-move data (or living data or data stream), where we may find that using interaction logic constructs that change state, such as if, for, and so on, is a poor performing choice together with a poor design. In-move data is any kind of data stream, such as a video stream, an application insights stream, and so on. Because of its statelessness, it is obvious that a stateless programming approach offers better results than a state-driven one.

We are used to dealing with static data, such as a variable, a database, or anything else such as some binary- or string-based data. All such data is data-at-rest, static data, or simply data.

As an example if we execute a select statement against a relational database, we will always have a result set containing the exact value contained in the database table at the specific time we executed the query. A second later, the table could experience an update statement that could change any row's data without the first client (the one executing the select statement) receiving an update on such data changes. To address these kinds of data changes without having to face issues between different relational database clients, there are optimistic and pessimistic concurrency checks (a bit outside the scope of this book). Obviously, the less we need to synchronize code to access a concurrent resource, the better our code will perform.

In imperative programming, control-flow is responsible for the good execution of the application. Such flow is usually made of multiple code rows that do something on input/output ports and somehow alter the application's state until the desired result is achieved, whereas in dataflow programming, data flows in and out of the different stages of a flowchart, as it behaves in a workflow.

Obviously, the different types of programming will greatly change the developers' experience and programming capability of the language. It is very difficult (and conceptually a bit wrong) to compute something by executing some interaction logic in data flow programming, because this kind of programming is simply outside the core design of the programming paradigm.

A practical example can be seen in data integrational , Extract, Transform, and Load (ETL) workflows, such as those available in SQL Server Integration Services (SSIS), as shown in the following screenshot. An ETL workflow has the task of reading (extracting) data from a data source (relational or not) and mapping (transforming) such data by grouping or aggregating it with other data sources or by executing transforming functions. Then, data flows (loads) into a target data store (relational or not) for future simplified access. SSIS is the tool for designing these kinds of workflows within the SQL Server Business Intelligence suite.

A SSIS dataflow task doing some transformations on data from a relational database

Generally speaking, outside the SQL server-oriented implementation of SSIS, within data flow programming, instead of having a huge code base in a high-level code, we have something like a data workflow. A digraph (directed graph)—an ordered version of a usual flowchart. Here is an example:

A simple representation of a dataflow digraph made of three recurring stages

Within the Microsoft universe, the only data flow programming compliant language is the Microsoft Visual Programming Language available for the Microsoft Robotics Developer Studio environment for robotics programming. Instead, SSIS simply uses data flows to handle data integrations between databases.

Functional programming is a programming paradigm that relies on the functional transformation of data between stages, not so different from the dataflow programming we just saw. The main addendum to the data flow paradigm is that, within the functional one, there is a specific functional transformation, while in the data flow paradigm such transformations occur in a specific idiom-based way that can be functional-based, script-based (imperative paradigm), component-based, or anything else.

In functional programming, data is always immutable and functions are responsible for data transformation. Anything in functional style is a data transformation. Although a decisional statement (if) cannot exist, a functional transformation from data containing predicate to data containing the Boolean result may occur:

//procedural style 
var sourceData = new { TotalAmount = 12345.67, PaidAmount = 12345.67 }; 
if (sourceData.PaidAmount == sourceData.TotalAmount) 
{ 
    //do something 
} 
 
//functional style 
//a simple enumerable 
new[] { new { TotalAmount = 12345.67, PaidAmount = 12345.67 } } 
//transformation block 
.Select(x => new 
{ 
    x.TotalAmount, 
    x.PaidAmount, 
    CanContinue = x.TotalAmount == x.PaidAmount, 
}) 
//if 
.Where(x => x.CanContinue) 
//do something 
.ToArray(); 

A widely known design pattern is the data mapper one. This design tries to decouple and translate objects of a layer (for historic purposes, the domain layer) into another one (for historic purposes, the data model one).

Here is a simple procedural (imperative with subroutines) programming style example in C#:

class Program 
{ 
    static void Main(string[] args) 
    { 
        //retrieve invoices from DB 
        var invoicesFromDB = GetInvoicesFromDB(); 
 
        //map those invoices to business model objects 
        var invoicesForBusiness = ConvertInvoicesForBusiness(invoicesFromDB); 
    } 
 
    /// <summary> 
    /// Reads invoices from a (fake) database 
    /// </summary> 
    /// <returns></returns> 
    static InvoiceFromDB[] GetInvoicesFromDB() 
    { 
        var result = new InvoiceFromDB[3]; 
 
        result[0] = new InvoiceFromDB 
            { 
                CustomerName = "Mr. Black", 
                Number = "100/2015/BBC", 
                BaseAmount = 24560, 
                VATMultiplier = 1.22, 
            }; 
 
        result[1] = new InvoiceFromDB 
            { 
                CustomerName = "White Co Ltd", 
                Number = "240/2015/BBC", 
                BaseAmount = 422480, 
                VATMultiplier = 1.22, 
            }; 
 
        result[2] = new InvoiceFromDB 
            { 
                CustomerName = "Green Woods inc.", 
                Number = "22/2015/BBC", 
                BaseAmount = 8500, 
                VATMultiplier = 1.22, 
            }; 
 
        return result; 
    } 
 
    /// <summary> 
    /// Converts invoices from database to invoices for business needs 
    /// </summary> 
    static InvoiceBusiness[] ConvertInvoicesForBusiness(InvoiceFromDB[] source) 
    { 
        var result = new InvoiceBusiness[source.Length]; 
 
        for (int i = 0; i < source.Length; i++) 
            result[i] = new InvoiceBusiness 
            { 
                Number = source[i].Number, 
                CustomerName = source[i].CustomerName, 
                BaseAmount = source[i].BaseAmount, 
                VATMultiplier = source[i].VATMultiplier, 
            }; 
 
        return result; 
    } 
} 
 
public class InvoiceFromDB 
{ 
    public string CustomerName { get; set; } 
    public string Number { get; set; } 
    public double BaseAmount { get; set; } 
    public double VATMultiplier { get; set; } 
} 
 
public class InvoiceBusiness 
{ 
    public string CustomerName { get; set; } 
    public string Number { get; set; } 
    public double BaseAmount { get; set; } 
    public double VATMultiplier { get; set; } 
    public double Total 
    { 
        get { return BaseAmount * VATMultiplier; } 
    } 
} 

In a functional style, the same program will benefit from the use of the enumerator pattern (for static data such as this one) or triggers that will notify for observed data changes.

Later, the transformation logic will take place within a function.

Here is the same preceding example in a functional style made with LINQ querying in C#:

class Program 
{ 
    static void Main(string[] args) 
    { 
        var businessInvoices = 
            //stage 1 - read db data 
            GetInvoicesFromDB() 
            //stage 2 - make transfomation 
            .Select(dbinvoice => new InvoiceBusiness 
            { 
                Number = dbinvoice.Number, 
                BaseAmount = dbinvoice.BaseAmount, 
                CustomerName = dbinvoice.CustomerName, 
                VATMultiplier = dbinvoice.VATMultiplier, 
            }) 
            //force execution of the whole enumerator 
            .ToArray(); 
    } 
 
    static IEnumerable<InvoiceFromDB> GetInvoicesFromDB() 
    { 
        yield return new InvoiceFromDB 
        { 
            CustomerName = "Mr. Black", 
            Number = "100/2015/BBC", 
            BaseAmount = 24560, 
            VATMultiplier = 1.22, 
        }; 
 
        yield return new InvoiceFromDB 
        { 
            CustomerName = "White Co Ltd", 
            Number = "240/2015/BBC", 
            BaseAmount = 422480, 
            VATMultiplier = 1.22, 
        }; 
 
        yield return new InvoiceFromDB 
        { 
            CustomerName = "Green Woods inc.", 
            Number = "22/2015/BBC", 
            BaseAmount = 8500, 
            VATMultiplier = 1.22, 
        }; 
    } 
} 
 
public class InvoiceFromDB 
{ 
    public string CustomerName { get; set; } 
    public string Number { get; set; } 
    public double BaseAmount { get; set; } 
    public double VATMultiplier { get; set; } 
} 
 
public class InvoiceBusiness 
{ 
    public string CustomerName { get; set; } 
    public string Number { get; set; } 
    public double BaseAmount { get; set; } 
    public double VATMultiplier { get; set; } 
    public double Total 
    { 
        get { return BaseAmount * VATMultiplier; } 
    } 
} 

What makes the preceding example different from the previous one is that the GetInvoicesFromDB method returns an enumerable collection. Although an array is enumerable too, an array is a finite item collection. In the procedural example, all contained objects must already be in our memory before the method returns values creating a huge data state. Later, in the imperative example, such a state will be changed by the other method ConvertInvoicesForBusiness that is responsible for creating business objects containing business stuff (Total in the preceding example).

In the functional style example, instead of having an interactive statement that processes data in the memory, we will simply write a new function able to transform the data-oriented object into the business-oriented one. This transformation is declaratively defined with a function. The function simply states how the transformation must happen. Thus, to trigger the concrete computation and the storage (in memory) of the transformed data, we will use the .ToArray() LINQ extension method that will evaluate the functional result and store such results into a finite item collection, the array.

At this point, the preceding functional programming examples should convince any reader that data-driven programming of in-move data in many programming scenarios may achieve a higher performance than imperative programming could ever do.

Reactive programming is the art of programming the propagation of changes. Think of an Excel function =A1+B2. This function will always contain the sum of the two cells; it will never contain a raw (or static) value that represents the sum at a specific time. It will always contain the updated sum of the two cells' values. Anytime the related cells raise a value update event (A1 and A2), the resulting cell will update the sum and show the new value. In C#, a similar behavior is available in a computed property, where the result is available only as a computation instead of a state value:

 public double TotalAmount { get { return 10d * 10d; } } 

Obviously, reactive programming is not simply a function or computed property. Specific designs and technologies are available and needed to develop using reactive programming. Let's start understanding such a new paradigm by reading its idea and its main characteristics and the available languages and idioms.

Although this book is about reactive programming, the most transforming modules we will write will observe the object-oriented programming paradigm. This is a good thought. Simply consider the following assertion: the best programming style or language is the best only in a few conditions. Accordingly, try your programming style to the task you're facing.

Here are some suggestions:

In this chapter, we had the opportunity to give an overall description of reactive programming frameworks and languages. Specific key concepts and designs are available for this programming paradigm.

In the next chapter, we will put into practice all such theoretic notions, writing examples in pure C#, and trying to understand all the key concepts and designs explained here.