Architecture Overview

Down the rabbit hole...

Although our final destination is a single page web application, it is not a traditional Angular application. The original source code was Silverlight, with some similarities and vast differences.

It is necessary to know how things work in the Silverlight world and how they get translated to understand the architecture of a migrated application, in order to make sense of some aspects which do not fit in a traditional Angular application.

Silverlight: where we came from...

In a nutshell, a Silverlight application uses XAML to declare it's user interfaces, and is programmed using a subset of .NET Framework. To run on the web, it requires the Silverlight plugin to be installed on the browser, which is only compatible with Internet Explorer. In a simplified form, a Silverlight application can be represented like this:

When migrating a Silverlight application, legacy code (XAML, C#) is converted to migrated code (HTML, CSS, TypeScript) which can be run on a modern browser (Chrome, Edge, etc.), without the need for any plugin:

However, it is not as simple as it seems. A few voids need to be filled before running the migrated application on a modern browser.

From .NET to Web: wms-framework

Silverlight applications run on top of a subset of the .NET Framework, which provides a lot of functionality out of the box. Some of this functionality can be mapped directly to JavaScript/TypeScript constructs or Web APIs, but other functionality simply does not have a natural equivalent on modern browser web environments. This is where wms-framework comes in.

wms-framework provides the functionality that was available to a Silverlight application, but is not present on modern web environments.

wms-framework is an npm package which provides the functionality that was available to a Silverlight application, but is not present on modern web environments. If a Silverlight application uses LINQ, wms-framework has equivalent functions to support the migrated application. If a Silverlight application uses reflection, wms-framework brings mechanisms to imitate reflection on the web.

Silverlight also provides basic controls to compose an application (buttons, labels, checkboxes, etc.). Similarly wms-framework provides models (ButtonModel, LabelModel, etc.) which mimics the properties and behavior of their equivalent Silverlight controls. A model is the representation of a Silverlight control in the migrated application. Both native and user created controls are migrated as models. This models should behave as closely to the original controls as possible.

A model is the representation of a Silverlight control in the migrated application.

A model is just an abstract representation of a Silverlight control: it is not directly rendered on the screen, and the user can not interact directly with the model. The Angular framework will be the one in charge of representing models on the screen, and provide user interaction.

In the browser screen: Angular

Models provide an accurate representation of the original Silverlight application behavior, but there is still the need to display that representation and interact with it on a browser. This is where Angular comes into the picture. Each model is wrapped inside an Angular component, which uses the Angular framework to render a representation of the model on the browser, and provides user interaction with the Angular component, which relays such interaction to the model.

For example, the ButtonModel from wms-framework is wrapped inside ButtonComponent, which is an Angular component that will render a <button> on the HTML DOM to represent the ButtonModel. If the ButtonModel is enabled or disabled, ButtonComponent will reflect that state on the <button> on screen. When the user clicks on the button on the screen, ButtonComponent will relay that action to ButtonModel, which in turn will react to such click action.

Every model in wms-framework has a corresponding Angular component. Those components have their own package, named i-components. A migrated application is build upon wms-framework and i-components, and both are build upon Angular framework to render and interact with the models.

Angular components on i-components are build upon Infragistics controls, hence the "i" on i-components. Documentation for Infragistics can be found here.

In summary, wms-framework provides the models for legacy controls, and also brings a lot of functionality that is available on Silverlight (like LINQ, collections, reflection, etc.) but is not natively available on a web environment. i-components provides a library of Angular components, ready to be used as wrappers around models.

Example: a single button

On legacy code

A Silverlight control is defined by two files: a XAML file and its companion C# file. The XAML file defines the structure and appearance of the control and the C# file defines the behavior.

The following code is an example of a simple user defined Silverlight control: it has one button, and it displays a "Hello world" message when the button is clicked. Don't worry too much about details, just take a look at <Button> on the XAML file (defining the appearance: just a button), and the clickHandler() function on the C# file (defining the behavior when we click on the button). Also, note that the user control name (MyControl in this case) is the name of the partial class on the C# file.

XAML: MyControl.xaml

<UserControl x:Class="Example.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <Button x:Name="button"
            Content="Click me!"
            HorizontalAlignment="Left"
            Margin="10,10,0,0"
            VerticalAlignment="Top"
            Width="75"
            Click="clickHandler"/>
    </Grid>
</UserControl>

C#: MyControl.xaml.cs

using System.Windows;
using System.Windows.Controls;

namespace Example
{
    public partial class MyControl : UserControl
    {
        public MyControl()
        {
            InitializeComponent();
        }

        private void clickHandler(object sender, RoutedEventArgs e)
        {
            MessageBox.Show($"Hello world!");
        }
    }
}

When this code is executed you should see something like this:

Hey wait, is that Internet Explorer? Yes. Remember that Silverlight code must be executed on Internet Explorer (with a Silverlight plugin), it can't be run on modern browsers (Chrome, Edge, Firefox, Safari... they don't talk to Silverlight). That's one reason why we need to migrate Silverlight code into something which can be run on modern platforms.

On migrated code

When migrating a Silverlight application, its parts are transformed into "equivalent" Angular parts. MyControl will be transformed into a model, with a corresponding Angular component to interact with it.

Following this architecture, a Silverlight control is converted into two entities:

A model.
An Angular component.

Most of the XAML code in a Silverlight control is migrated into the Angular component. The C# code of the Silverlight control is migrated to TypeScript into the model:

A typical Angular component is usually made of three files:

A TypeScript class.
An HTML template.
A CSS (or SCSS) style sheet.

The XAML code from a Silverlight control ends up mainly in the HTML template (and SCSS style sheet) in the Angular component. The TypeScript class is connected to the migrated model.

So a Silverlight user control made up of two files (MyContol.xaml and MyControl.xaml.cs) is migrated into four files:

MyControl.ts (the model)
The Angular component:
- MyControl.component.html (HTML template)
- MyControl.component.scss (Style sheet)
- MyControl.component.ts (component class)

Looking at our previous Silverlight code example, it will be migrated to something like this:

Note how the clickHandler() function from C# ends up in the model, in this case in a TypeScript class called MyControl. The <Button> from XAML is also a Silverlight control, so it is migrated into two entities as well:

A <wm-button> on the HTML template, in the Angular component.
A ButtonModel (named button) on the migrated model.

The <wm-button> on the HTML template defines the structure (appearance) of the user defined control, the same as it did on XAML. The ButtonModel inside the model helps when the code behind interacts directly with the button.

On the original code <Button> and clickHandler() were connected. How is the migrated <wm-button> connected with the migrated clickHandler()? On XAML we connected the click event from the Button with the clickHandler() function from C# using the Click property like this:

<Button Click=“clickHandler”/>

On the migrated application, on the HTML template, this becomes:

<wm-button (click)=“model.clickHandler($event.sender,$event.e)”>

clickHandler() is called through model, which is a property on MyControlComponent (the Angular component class) which points to the model (MyControl). The model property is the point where the Angular component connects with the migrated Silverlight model.

The model property in the component class is the point where the Angular component connects with the migrated model.

PreviousRelease Notes NextPRISM support

Last updated 3 years ago

Was this helpful?