Living in the Tech Avalanche Generation

Ever since reading Programming C# I have been a fan of Jesse Liberty’s unique way of writing learning material and so when I was looking for Silverlight content I was very pleased to find Jesse’s tutorials.

I found these tutorials useful however I am one of those people that need to print material that I use to learn from rather than flipping from window to window (or monitor to monitor). So as per my modus operandi I condensed Jesse’s tutorial’s into a single PDF and you find it here if your like me and prefer to print the whole lot out. Here are the original posts.

In my recent efforts to get familiar with Silverlight it became apparent to me that the first basic skill to build strongly was LAYOUT! I decided that to really create a profound sense of ease and understanding I would need firstly to become as fluent as possible in laying out my UI in this new environment. This was something that I had begun to take for granted in Windows and Web Forms after years of experience had been ploughed into those technologies. Given the nature of XAML based UI’s it was clear that this was not just going to be a ’shift of tools’ kind of experience but more a ’shift of paradigm’ experience altogether. XAML based UI’s are of course declarative and whilst it’s true that ASP.Net UI design is declarative to some degree by virtue of its being ultimately rooted in HTML, Windows Forms is quite a different beast and XAML is after all the new UI technology of the desktop and carries with it the hopes and dreams of those that were swept away in the past by the ActiveX and Java Applet phenomenon’s that promised so much and did not ultimately deliver.

Layout of Windows and Web Forms can be a very designer IDE driven experience (more so in Windows Forms) and it became immediately apparent that the tools (Blend and VS.NET) are not currently as established in as the ‘old guard’, however I do believe that this temporary circumstance offers an upside. Having to dig deeper into the XAML because the tools require you too, makes for developing a deeper understanding and at this early stage that will turn into a definite plus - there are always advantages to knowing how to tweak deep under the hood. I have known developers to live in blissful ignorance of the low level details and never question what all the designer code was doing but in my opinion this isn’t an option with Silverlight right now as the designers are not yet mature or sophisticated enough to abstract us away from the goo so deeply quite yet.

Let’s compare the two experiences by way of example. In the first instance we will build a completely trivial and useless UI that is simply only useful in demonstrating the difference of approaches.

Figure 1.0

(note the lines in the middle is splitter being dragged)

As you may see from figure 1.0, we have a toy form with two panels split by a System.Windows.Forms.Splitter, throw in some docking and you very quickly have a dynamically growing and shrinking UI. The code for this would not be described as declarative however and courteousey of our VS.Net designer generated code all this gets built in a ‘form_name.designer.cs’ file which developers should in fact make their mission in life to avoid changing as it’s a practice that’s encumbered with the age old Code Gen problem of loss of synchronisation.

Listing 1.0

partial class Form1
{
    /// <summary>
    /// Required designer variable.
    /// </summary>
    private System.ComponentModel.IContainer components = null;

    /// <summary>
    /// Clean up any resources being used.
    /// </summary>
    /// <param name=”disposing”>true if managed resources should be
    ///  disposed; otherwise, false.</param>
    protected override void Dispose(bool disposing)
    {
        if (disposing && (components != null))
        {
            components.Dispose();
        }
        base.Dispose(disposing);
    }

    #region Windows Form Designer generated code

    /// <summary>
    /// Required method for Designer support - do not modify
    /// the contents of this method with the code editor.
    /// </summary>
    private void InitializeComponent()
    {
        this.panel1 = new System.Windows.Forms.Panel();
        this.splitter1 = new System.Windows.Forms.Splitter();
        this.panel2 = new System.Windows.Forms.Panel();
        this.button1 = new System.Windows.Forms.Button();
        this.textBox1 = new System.Windows.Forms.TextBox();
        this.textBox2 = new System.Windows.Forms.TextBox();
        this.textBox3 = new System.Windows.Forms.TextBox();
        this.textBox4 = new System.Windows.Forms.TextBox();
        this.button2 = new System.Windows.Forms.Button();
        this.panel1.SuspendLayout();
        this.panel2.SuspendLayout();
        this.SuspendLayout();
        // 
        // panel1
        // 
        this.panel1.Controls.Add(this.textBox2);
        this.panel1.Controls.Add(this.textBox1);
        this.panel1.Controls.Add(this.button1);
        this.panel1.Dock = System.Windows.Forms.DockStyle.Top;
        this.panel1.Location = new System.Drawing.Point(0, 0);
        this.panel1.Name = “panel1″;
        this.panel1.Size = new System.Drawing.Size(463, 120);
        this.panel1.TabIndex = 0;
        // 
        // splitter1
        // 
        this.splitter1.BorderStyle =
            System.Windows.Forms.BorderStyle.FixedSingle;
        this.splitter1.Dock = System.Windows.Forms.DockStyle.Top;
        this.splitter1.Location = new System.Drawing.Point(0, 120);
        this.splitter1.Name = “splitter1″;
        this.splitter1.Size = new System.Drawing.Size(463, 10);
        this.splitter1.TabIndex = 1;
        this.splitter1.TabStop = false;
        // 
        // panel2
        // 
        this.panel2.BorderStyle =
            System.Windows.Forms.BorderStyle.FixedSingle;
        this.panel2.Controls.Add(this.button2);
        this.panel2.Controls.Add(this.textBox4);
        this.panel2.Controls.Add(this.textBox3);
        this.panel2.Dock = System.Windows.Forms.DockStyle.Fill;
        this.panel2.Location = new System.Drawing.Point(0, 130);
        this.panel2.Name = “panel2″;
        this.panel2.Size = new System.Drawing.Size(463, 168);
        this.panel2.TabIndex = 2;
        // 
        // button1
        // 
        this.button1.Location = new System.Drawing.Point(279, 23);
        this.button1.Name = “button1″;
        this.button1.Size = new System.Drawing.Size(152, 53);
        this.button1.TabIndex = 0;
        this.button1.Text = “button1″;
        this.button1.UseVisualStyleBackColor = true;
        // 
        // textBox1
        // 
        this.textBox1.Location = new System.Drawing.Point(24, 23);
        this.textBox1.Name = “textBox1″;
        this.textBox1.Size = new System.Drawing.Size(158, 20);
        this.textBox1.TabIndex = 1;
        // 
        // textBox2
        // 
        this.textBox2.Location = new System.Drawing.Point(23, 56);
        this.textBox2.Name = “textBox2″;
        this.textBox2.Size = new System.Drawing.Size(158, 20);
        this.textBox2.TabIndex = 2;
        // 
        // textBox3
        // 
        this.textBox3.Location = new System.Drawing.Point(20, 37);
        this.textBox3.Name = “textBox3″;
        this.textBox3.Size = new System.Drawing.Size(161, 20);
        this.textBox3.TabIndex = 0;
        // 
        // textBox4
        // 
        this.textBox4.Location = new System.Drawing.Point(20, 72);
        this.textBox4.Name = “textBox4″;
        this.textBox4.Size = new System.Drawing.Size(162, 20);
        this.textBox4.TabIndex = 1;
        // 
        // button2
        // 
        this.button2.Location = new System.Drawing.Point(279, 37);
        this.button2.Name = “button2″;
        this.button2.Size = new System.Drawing.Size(152, 54);
        this.button2.TabIndex = 2;
        this.button2.Text = “button2″;
        this.button2.UseVisualStyleBackColor = true;
        // 
        // Form1
        // 
        this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
        this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
        this.ClientSize = new System.Drawing.Size(463, 298);
        this.Controls.Add(this.panel2);
        this.Controls.Add(this.splitter1);
        this.Controls.Add(this.panel1);
        this.Name = “Form1″;
        this.Text = “Form1″;
        this.panel1.ResumeLayout(false);
        this.panel1.PerformLayout();
        this.panel2.ResumeLayout(false);
        this.panel2.PerformLayout();
        this.ResumeLayout(false);

    }

    #endregion

    private System.Windows.Forms.Panel panel1;
    private System.Windows.Forms.TextBox textBox2;
    private System.Windows.Forms.TextBox textBox1;
    private System.Windows.Forms.Button button1;
    private System.Windows.Forms.Splitter splitter1;
    private System.Windows.Forms.Panel panel2;
    private System.Windows.Forms.Button button2;
    private System.Windows.Forms.TextBox textBox4;
    private System.Windows.Forms.TextBox textBox3;
}

Clearly all this code builds our UI step wise fashion at run time. In XAML however you state your intention declaratively and the runtime takes that stated intention and displays it for you in the form of a UI. This Windows Form was entirely built using Drag and Drop and required no tweaking by hand. To do a similar type of thing in Silverlight of course we would expect to look quite a bit different. Note the use of the GridSplitter which is not a standard Silverlight control, it is part of the Silverlight Control Set which is available on CodePlex.

Listing 2.0 and Figure 2.0 below both demonstrate a similar layout concept in Silverlight however the difference is that it’s totally declarative, the runtime will determine how to render to the UI based on the stated intent of the XAML. In essence the theme of this post is really about what I found important for me in making the switch over to the XAML based UI technologies and that was to firstly become as comfortable and familiar in laying out my UI as I have been in the already existing UI frameworks. Once this goal is achieved it’s on to integrating familiar patterns and frameworks with XAML such as MVC / MVP and IoC.

Listing 2.0

<UserControl
    xmlns:basics=”clr-namespace:System.Windows.Controls;
                  assembly=System.Windows.Controls”
    x:Class=”LayoutSilverlightUserControls.Page”
    xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”
    xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
    Width=”400″ Height=”300″>
    <Grid x:Name=”LayoutRoot” Background=”White” Width=”400″ Height=”400″>
        <Grid.RowDefinitions>
            <RowDefinition Height=”*” MinHeight=”100″/>
            <RowDefinition Height=”Auto” />
            <RowDefinition Height=”100*” MinHeight=”200″/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition />
        </Grid.ColumnDefinitions>
        <basics:GridSplitter x:Name=”grsplSplitter” Grid.Row=”1″
            Grid.Column=”0″ VerticalAlignment=”Center”
            HorizontalAlignment=”Stretch” Background=”Black”
            ShowsPreview=”False” Height=”2″>
        </basics:GridSplitter>
        <StackPanel Grid.Row=”0″ Grid.Column=”0″ Orientation=”Vertical”
                    VerticalAlignment=”Bottom” Margin=”10″>
            <StackPanel Orientation=”Horizontal” Margin=”5″>
                <TextBox Width=”300″></TextBox>
                <Button Width=”60″ Content=”Button1″></Button>
            </StackPanel>
            <StackPanel Orientation=”Horizontal” Margin=”5″>
                <TextBox Width=”300″></TextBox>
                <Button Width=”60″ Content=”Button2″></Button>
            </StackPanel>
        </StackPanel>
        <StackPanel Grid.Row=”2″ Grid.Column=”0″
                    Orientation=”Vertical”
                    VerticalAlignment=”Top” Margin=”10,0,0,0″>
            <StackPanel Orientation=”Horizontal” Margin=”5″>
                <TextBox Width=”300″></TextBox>
                <Button Width=”60″ Content=”Button3″></Button>
            </StackPanel>
            <StackPanel Orientation=”Horizontal” Margin=”5″>
                <TextBox Width=”300″></TextBox>
                <Button Width=”60″ Content=”Button4″></Button>
            </StackPanel>
        </StackPanel>
    </Grid>
</UserControl>

Figure 2.0

How quickly will people start working in WPF in deference to Windows Forms or ASP.Net Web Forms? What are the core set of questions that need answering before choosing the right technology? Subject of a latter post no doubt.

The most canonical example usage of WCF Transactions (according to Juval) is the following :

A client application wraps (n) service calls in a single transaction and relies on the ACID safe haven of System.Transaction to save the day. In my opinion, one of the core characteristics of WCF is that it’s design favours (and Microsoft like to demonstrate it’s usefulness via) a remote object pattern where developers program against an objects polymorphic signatures i.e. its behavioural aspects, via a proxy. This can be seen when we consider code such as proxy.UpdateAccount(); or proxy.RemoveCustomerPurchase(Guid purchaseID); for example, where proxy is a variable name for an object classed from a CustomerAccount class or more precisely implementing the ICustomerAccount interface and it’s operation contracts. Why am I highlighting this design characteristic? It’s my view that this characterstic has permeated it’s way into the entire design of WCF and it’s impact is felt an many corners of the Platform and affects us for example in the choices we are required to make on concurrency and instancing, however before we get into that let’s look at the example below as per the canonical example.

Figure 1.0

Listing 1.0

public void Call_A_B_C(Guid purchaseId)
{
    //…..create the binding and the addresses
    ChannelFactory<ServiceA> factoryA =
        new ChannelFactory<ServiceA>(bindingA, addressA);
    IServiceA channelA = factoryA.CreateChannel();

    ChannelFactory<ServiceB> factoryB =
        new ChannelFactory<ServiceA>(bindingB, addressB);
    IServiceB channelB = factoryB.CreateChannel();

    ChannelFactory<ServiceC> factoryC =
        new ChannelFactory<ServiceC>(bindingC, addressC);
    IServiceA channelC = factory.CreateChannel();

    using(TransactionScope scope = new TransactionScope())
    {
        channelA.RemoveCustomerPurchase(purchaseId);
        channelB.UpdateInventoryRequest(purchaseId);
        channelC.AmendBillingNotice(purchaseId);
        scope.Commit();
    }

    //…..etc
}

Let’s also assume that our Services A, B and C have the following Transaction flow attributes setup correctly so our client initiated (ambient) transaction flows through to the services.

[ServiceContract]
public interface IServiceA
{
    [OperationContract]
    [TransactionFlow(TransactionFlowOption.Mandatory)]
    public bool RemoveCustomerPurchase(Guid purchaseId);
}

public class ServiceA : IServiceA
{
    [OperationBehaviour(TransactionScopeRequired = true)]
    public bool RemoveCustomerPurchase(Guid purchaseId)
    {
        //…Database access etc…
    }
}

The idea here of course is that calling all three services in a single transaction will make our services behave in a way where the state of our systems (most likely kept in a database repository) will remain consistent in the case of a failure at any point through the transaction - it’s an all or nothing proposition. Combined, this aggregation of requested operations represents a discrete logical business workflow of some kind, where all operations or business actions must succeed or fail as a single ATOMIC transaction.

Again let’s note that these (three) operations (service method calls) are modelled more like traditional business object behaviours and will likely include some database interaction (we will talk about the File IO in figure 1.0 further on) and other potentially long running code. These operations typically implement a request / response message exchange pattern and by lining up all three of these requests inside a transaction and locking resources we are immediately creating a friction with our ability to scale and increasing our chances of encouraging database deadlocks and service  timeouts. Also worth noting is that the default IsolationLevel for the TransactionScope is Serializable which happens to be the most expensive Isolation Level and will lock whatever our service touches until it’s finished doing it’s work.

As a consultant I have seen my share of Web / WCF Services running out there in the wild and it’s pretty common to see them spread over a variety of IIS machines and in some Windows Services running under the SCM and furthermore some of these services are large (have hundreds of operations) and have lots of database access code and they all hit the same tables in the same DB’s in any variety of order. For example, in our example above, it’s not uncommon to see Service A, B and C all accessing the same database and tables and it’s also common for a variety of disparate applications to use all three services independently and not in a universally consistent manner. Lets say we have client X which uses Service A and C and client Y which uses Service A, B and C and client Z which uses Service A only. Imagine that these client applications use any number of permutations in aggregating service method calls within a surrounding transaction; while these long running operations are having distributed locks applied to both the services and database queries, other client requests are waiting and become more likely to timeout.

This approach does not scale. So let’s imagine we are using RepeatableRead for an isolation level (not the default Serializable) and we have multiple clients making distributed transaction calls across services, all the locking going on in the database is going to slow things up and our services will be waiting for locks to release, which in turn will make our clients wait for our services to return responses and gradually our system will grind and timeout, suffering more and more as further users come on line. Their is an underlying complexity with WCF declarative architecture, many configuration options that can be strung together to state an intent about instancing concurrency, ATOMICITY, transport characteristic, security and the list goes on. Sometimes its possible to create a collection of declarative statements that are acceptable however when applied are redundant or countermanding. It’s possible in the scenario we are discussing that service operations under load be queuing up calls and locking out other clients whilst this potentially weighty transaction is occurring across different web servers and databases and should one of them start to cave in under this load then our system is going to spiral down and every part of it will probably become non-responsive. In the meantime who knows how many important messages are being lost on the wire without any store and forward strategy. These are indeed some of the reasons that distributed transactions are a bad idea and that it may be worth considering transactional asynchronous messaging in these scenarios. Store your message and then get it across the wire under a transaction (so it’s not lost) letting each endpoint worry about storing their own messages and processing them under the steam of a different thread than that managing the Service method. You could of course use MSMQ binding but it’s a limiting design choice and if you require HTTP as the transport it’s not viable. Also, if you have to deal with state at the point of handling the message, then Separating the threads or perhaps even the processes for dealing with the concerns of receiving the message and handling messages, makes for a more scalable and performant system, lending itself well to dealing with long living service state. Perhaps your service design includes dealing with various messages over time, where the messages need to be correlated to one another as in a Saga.

Client passes message and flows transaction to >> Service A >> Service A passes message and flows transaction to >> Service B >> Service B passes message and flows transaction to >> Service C. Now if anything goes wrong in the hops between client and services here then we expect everything that happened to be rolled back right? Wrong! With ASMX or WCF out of the box bindings that don’t include MSMQ, there is no durable storage of our messages, so if the client below in Figure 2.0 sends an order, something goes wrong somewhere and we roll back, we just lost our message (hope it wasn’t an order right?). Furthermore, in Figure 2.0 we could add more clients which use any one of the services depicted exclusively, for example Client B comes along and calls Service C only, meanwhile the depicted client (A) is making an distributed transaction across aggregated calls to Service A, B and C where it currently is waiting for Service A to complete its work. Service A (on behalf of client A) is accessing the same database table as Service C (on behalf of client B) - there is a deadlock in the database, a victim is chosen and someone rolls back, however whilst they were blocking and the transactions were open on our Per Call, Single entrant WCF Services, all the other clients requesting work were held up and waiting and potentially timed out as well.

Figure 2.0

It’s generally a good idea to keep your transactions in WCF open for as short a period of time as possible and that’s why using WCF as pure message transport (i.e. absolutely no business logic or database interaction) can help you achieve better throughput, scale and be more fault resistant. Transport your messages transactionally from queues (where the message originates) and to other queues located at the message destination, this will protect against lost messages; it’s possible to use WCF entirely as the transport protocol enabler of choice and not follow the CRUD RPC styled messaging pattern.

Figure 3.0

Because we read the message off the originating queue and send it to target queue within the scope of a transaction, our message will simply roll back of there’s a problem. If we pursue the concepts outlined in Figure 3.0 to their conclusion, we might consider MSMQ or SQL Service Broker to provide us with our Queues and Service Broker does offer us some potential Smart Client benefits in being so close to our endpoints in this design scenario. Let’s be clear however, we are proposing using Service Broker for it’s queues and only it’s ability to provide queues, we do not propose to build services, contracts et al in Service Broker, thus avoiding any ensuing licensing issues which Service Broker will create if you implement your services using that technology.

Its no secret that I am fan of LINQ To SQL, this blog gave berth to the LINQ To SQL support bumper sticker and I have recently shouted out my disappointment regarding the back seat that the product seems to be taking to the Entity Framework. In a bid to know more about the Entity Framework I recently consolidated Julie’s series of posts into a single PDF for ease of reading. I have also earmarked Julie’s book to take the learning to the next level and I sincerely hope I am won over by the product. I will from time to time check in with a post to update with my observations and of course will no doubt compare what I find with what I had already grown to love.

You can find the Julie’s original posts below or simply follow the link on the image here and it will take you to the consolidated PDF version of the series of post.

Creating an ADO.NET Entity Framework Entity Data Model

Use an Entity Framework Entity as a WinForms Data Source

Using Stored Procedures for Insert, Update & Delete in an Entity Data Model

ASP.NET DataBinding with LINQ to Entities

WPF Databinding with Entity Framework

Many to Many Relationships in the Entity Data Model