The SPA will have access token only when the user has logged in to the Authorisation server. The client can access the protected API using the access token which has the required scope. We are not speaking of token management here, but client secret management.

Now when a user is still anonymous, we still need to provide them with data from our API. Secret management on client side is not a viable option. The only place client secret can be safely stored is with a trusted client which runs on the server side.
There is an active doc by IETF which guides you on using OAuth with browser based apps here. Based on their recommendation at 6.2 we can move the authentication and token management to the ASP.NET Core app which shares the domain with the SPA. The token/session management would be done by Cookies with HttpOnly and Lax or Strict SameSite mode. Check out this blog for more details on SameSite Cookie.

This way we are moving all the authentication to the server and a machine to machine communication takes place through which a token is requested on behalf of the clients.
The BFF (Backend for front end) architecture is more common with Microservices and sometime also referred to as API Gateway. Personally, in this scenario I would lean more towards calling this as a BFF pattern since this nomenclature makes the intent more clearer that we are introducing this API specifically for a front-end, namely SPA.

Let us see what goes in to implement such an API.
In the same ASP.NET Core site which serves the static content you can setup session management and forwarding the requests to the backend API along with attaching a valid access token.
In Startup.cs

1
2
3
4
5
6
7
8
9
10
11
12

private const string Authority_TokenEndpoint = "http://localhost:62000/connect/token";
private const string token_cookie_name = "code.token";
public void ConfigureServices(IServiceCollection services)
{
    services.Configure<CookiePolicyOptions>(options =>
    {
        options.HttpOnly = Microsoft.AspNetCore.CookiePolicy.HttpOnlyPolicy.Always;
        options.MinimumSameSitePolicy = SameSiteMode.Strict;
    });
    services.AddHttpClient();
    services.AddProxy();
}

You might have noticed line AddProxy(). This is from ProxyKit. A light-weight, code-first HTTP reverse proxy. In this case it deals with the mundane task of forwarding requests to the back-end API with ease and style. It is very powerfull and you can do a lot more with it.
Let is see how we use it next.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseCookiePolicy();
string tokenForCookie = "";
app.Use(async (context, next) =>
{
// get access token
var factory = app.ApplicationServices.GetRequiredService<IHttpClientFactory>();
var client = factory.CreateClient();
var tokenResponse = await client.RequestClientCredentialsTokenAsync(
            new ClientCredentialsTokenRequest
{
Address = Authority_TokenEndpoint,

ClientId = "securebff",
ClientSecret = "secret",
Scope = "externalapi"
});
// check if we have a valid response
tokenForCookie = tokenResponse.AccessToken;
var expiresin = DateTime.Now.AddSeconds(tokenResponse.ExpiresIn);
// save to cookie
CookieOptions options = new CookieOptions
{
IsEssential = true,
HttpOnly = true,
SameSite = SameSiteMode.Strict,
Secure = env.IsDevelopment() ? false : true,
Expires = expiresin
};
context.Response.Cookies.Append(token_cookie_name, tokenForCookie, options);
await next();
});
app.Map("/external", api =>
{
api.RunProxy(async context =>
{
var forwardContext = context.ForwardTo("http://localhost:5000/api/test");

var token = string.IsNullOrEmpty(tokenForCookie) 
            ? context.Request.Cookies[token_cookie_name] 
            : tokenForCookie;

forwardContext.UpstreamRequest.SetBearerToken(token);
forwardContext.AddXForwardedHeaders();
// add retry on 401 or other conditions
var response = await forwardContext.Send();
return response;
});
});
app.UseStaticFiles();
}

That’s it! As we receive a request, it creates a new token. Here I am using IdentityModel.Client to retrieve an access token from the STS end-point. It creates a cookie with the provided options and saves the token. If the request is for an external API protected by the access token, then the map would attach the current access token and forward the request to the external API and return the response.
Of course I have omitted checks like cookie existence, token expiration and skipping token retrieval for every requests for brevity. Also the STS and external API are not shown here, but there is nothing different about them here.

For completeness here is the new flow.

Some parting notes to consider. The activation of BFF component need not be that long when the token is retrieved from the cookie for subsequent requests. The SameSite cookie helps in stopping CSRF attacks. I am not sure if this completely shields you in XSS attacks. You would be adding additional server round-trips. It’s for you to decide if this choice suits your architecture.

Let us work with a model shown below

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class Student
{
    public int Id { get; set; }

    public string Name { get; set; }

    public Address Home { get; set; }
}

public class Address
{
    public string Street { get; set; }

    public string City { get; set; }
}

Here Student owns Address which is the owned type and does not have its own identity property. Address becomes a navigation property on Student and would always have an one-to-one relationship (at least for now).

The DbContext would be defined like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class StudentContext : DbContext
{
    public DbSet<Student> Students { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Student>()
            .OwnsOne(s => s.Home);
    }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer("Server=(localdb)\\mssqllocaldb;Database=StudentDb; Trusted_Connection=True;App=StudentContext");
        optionsBuilder.EnableSensitiveDataLogging();
    }
}

An owned type cannot have a DbSet<> and OnModelCreating you can specify the Home property as Owned Entity of Student.

Home would be mapped to the same table as Student.

Let us fire up this model and see it working.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

using Microsoft.EntityFrameworkCore.Infrastructure;
using Microsoft.Extensions.Logging;

class Program
{
    static void Main(string[] args)
    {
        var _context = new StudentContext();
        _context.GetService<ILoggerFactory>().AddConsole();
        _context.Database.EnsureDeleted();
        _context.Database.EnsureCreated();

        InsertStudent(_context);
    }

    private static void InsertStudent(StudentContext context)
    {
        var student = new Student
        {
            Name = "Student_1",
            Home = new Address
            {
                Street = "Circular Quay",
                City = "Sydney"
            }
        };
        context.Students.Add(student);
        context.SaveChanges();
    }
}

I have added Microsoft.EntityFrameworkCore.SqlServer and Microsoft.Extensions.Logging.Console packages.
From the console logs we see that we have Students table created and a row inserted.

1
2
3
4
5
6
7

CREATE TABLE [Students] (
    [Id] int NOT NULL IDENTITY,
    [Name] nvarchar(max) NULL,
    [Home_City] nvarchar(max) NULL,
    [Home_Street] nvarchar(max) NULL,
    CONSTRAINT [PK_Students] PRIMARY KEY ([Id])
);

To query, just get the students and the owned entity is also included.

1

var students = _context.Students.ToList();

We can also store Address in another table, which we can’t do with complex types in EF6. Simply call .ToTable() and provide a different name.

1
2
3

modelBuilder.Entity<Student>()
    .OwnsOne(s => s.Home)
    .ToTable("HomeAddress");

Now when you run the app, you would see 2 tables being created. Note the identity column for the HomeAddress table. It is referencing Students table’s identity.

1
2
3
4
5
6
7
8
9
10
11
12

CREATE TABLE [Students] (
    [Id] int NOT NULL IDENTITY,
    [Name] nvarchar(max) NULL,
    CONSTRAINT [PK_Students] PRIMARY KEY ([Id])
);
CREATE TABLE [HomeAddress] (
    [StudentId] int NOT NULL,
    [City] nvarchar(max) NULL,
    [Street] nvarchar(max) NULL,
    CONSTRAINT [PK_HomeAddress] PRIMARY KEY ([StudentId]),
    CONSTRAINT [FK_HomeAddress_Students_StudentId] FOREIGN KEY ([StudentId]) REFERENCES [Students] ([Id]) ON DELETE CASCADE
);

You can ignore properties which you do not want EF tracking.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class Address
{
    public string Street { get; set; }

    public string City { get; set; }

    public string State { get; set; } // ignore this
}

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Student>()
        .OwnsOne(s => s.Home, (h) =>
        {
            h.Ignore(a => a.State);
            h.ToTable("HomeAddress");
        });
}

There are certain elements to keep in mind especially with change tracking. With EF core do not assume the same code of EF6 would give you similar behaviour. This is especially true with Change Tracking. In my view these changes are welcome and makes tracking more intuitive and easy to navigate.

When you use Add, Attach, Update or Remove on either DbSet<> or through DbContext, it effects all reachable entities. Here is what it would look like:

1

context.Students.Add(student);

This would also mark Address in a Added state.
But if you do not want to track all the entities in the graph:

1

context.Entry(student).State = EntityState.Added;

When you do this only the student is marked for insert and address is not. So how do you only change the state of address?

1
2

var address = _context.Entry(student).Reference(s => s.Home).TargetEntry;
address.State = EntityState.Unchanged;

When you mark an entity in the graph for update, all the properties are marked for update. In a disconnected (n-tier) scenario, you would need to track changes on your entity externally and let EF know about the changes. You need to have the original state of the entity and do some processing to know which properties were changed. Or you could go back to the database, get the entity and compare it’s state.

1
2
3
4

var entry = _context.Attach(student);
var dbValues = entry.GetDatabaseValues(); // gets only the student
entry.OriginalValues.SetValues(dbValues);
_context.SaveChanges();

This would only update those columns which had any changes on them. But it would only affect the student object and not the address. The address would still be in an Unchanged state. The above entry.GetDatabaseValues() would fetch only student values and not address. For you to track changes on address, you would need to explicitly check on its entity.

1
2
3
4
5

var entry = _context.Attach(student);
var adEntry = _context.Entry(student.Home);
adEntry.OriginalValues.SetValues(adEntry.GetDatabaseValues()); // gets home address
entry.OriginalValues.SetValues(entry.GetDatabaseValues()); // gets student
_context.SaveChanges();

Now on SaveChanges(), it would issue update on Address too if it found any changes.

Under windows event log I saw this
IIS-W3SVC-WP(2307)

The worker process for application pool <Pool Name> encountered an error ‘Cannot read configuration file’ trying to read configuration data from file ‘\\?\<EMPTY>’, line number ‘0’. The data field contains the error code.

I knew for sure that the update had caused this issue as I was working on this particular web site just before the restart prompted me to close down my work.

I started looking at the user account under which I was running the app pool. It checked out fine. Next I just went and cleared off all the files under the Inetpub\temp folder. After restarting the services the web site came up without fuss this time.

I got curious since I had no idea what had caused the issue in the first place and started searching for support articles and came across this Web applications return HTTP Error 503 and WAS event 5189 on Windows 10 Version 1709 (Fall Creators Update)

This explained why I was facing the issue though the error message and the event logged was different. You also require to stop W3SVC service which the article missed(?) without which some files cannot be deleted and Remove-Item fails.

Solution
Stop “Windows Process Activation Service” and “W3SVC” service and clean out (delete) all the files under C:\Inetpub\temp\AppPools*. Start your services and the sites should be back to work.

I have always found WCF to be a great technology for many use cases. Before I ruffle anyone’s feathers out there, I love what Web API is capable of and if I am looking at providing HTTP services or anything which is targeted over internet, I would blindly choose Web API.
I am also eagerly waiting to see WCF service framework becoming a part of .NET Core. We already have the WCF client libraries available for the .NET Core version.
Having cleared that up, let me get back to one such use case for WCF, making a fire and forget call or one-way. This is useful when the client truly does not bother about the result or when it needs to kick off a process on the server and does not want to wait for it to finish, usually long running.
WCF’s comes with great variety, power and flexibility, but to truly harness it, one needs to have a deep understanding of its internals. You can use it out of the box without much mucking around, but sometimes it’s behaviour may not be obvious.

A quick recap on WCF one-way pattern.
The default behaviour of a service is request-reply pattern and to make it one-way you simply set the OperationContract as IsOneWay.

1
2
3
4
5
6

[ServiceContract]
public interface IOneWayService
{
[OperationContract(IsOneWay = true)]
void Process(int seed);
}

A few things to keep in mind when decorating an Operation as one-way.

• The method has to return void
• You cannot return Faults to the client. That means you cannot decorate the operation with FaultContract(typeof(Exception)) attribute.

Even if you unintentionally did the above on an one-way operation, the service would throw an error when attempting to start it.

Your service implementation is going to be nothing different here and so would the hosting part of it. So I won’t be delving in to it. You can simulate some load in it by doing a Thread.Sleep. So, would one get fire and forget operation form your client’s? It depends.
In fact it depends on quite a few things. First let us see what we can expect with our current implementation. Let me show you my client proxy first.

1
2
3
4
5
6
7

public class OneWayProxy : ClientBase<IOneWayService>, IOneWayService
{
public void Process(int seed)
{
Channel.Process(seed);
}
}

I like to hand-code my proxy / client for the service. I’ll probably keep that for another post. I also implement my clients different to what I have shown here, but this too is better than the freebie client you get from Visual Studio.

Let us look at the code calling our client.

1
2
3
4

OneWayProxy proxy = new OneWayProxy();
proxy.Process(5);
//proxy.Process(10);
proxy.Close();

The input parameter is just to make the service look important.

Here is what we see from running this implementation.

1. The call to the proxy would be asynchronous (at the client). You can uncomment the next call and verify that. They would not block.
2. Closing the channel might block. If the binding used is NetTcpBinding, by default it supports transport-level sessions. Which means the channel is kept open until the server completes processing all the client’s calls. If you use transport without a session, like basicHttpBinding, then the closing of channel would not block.
3. The calls are dispatched synchronously on the service. Meaning, your next call would only get processed after completing the previous.

So what we learn is using One-way throws up a few surprises. It is fire & forget only for the operation calls. When you are having long running processes, you might not always want to wait for the operations to complete to close the channel. And Yes! You should always close the channel so that they are returned back to the servers pool.

Since most uses of WCF within the firewall would use or prefer TCP protocol over HTTP for speed and security and I would like to close my channel after each call is made,but not have it blocked, the above implementation would not be the most useful.

So what are our options here?
To close the proxy before the operation finishes -

• We can use a session less transport, such as BasicHttpBinding or turn on Reliable session on NetTcpBinding. TCP binding provides reliability at transport level, but you get message level reliable session by enabling explicitly at the binding. But this comes at a cost overhead since a lot more messages are exchanged between the client and server to ensure this. This would also not give the best performance due to its chatty nature. <reliableSession enabled="true" />

• You can mark the NetTcpBinding by turning off the session support. This is done by marking the binding as ‘oneWay’. This requires you to create a custom binding which turns off session support on NetTcpBinding. This would not block the channel from closing. In the below example we have adding tcpTransport support.

  1 2 3 4 5 6 7 8

  <bindings> <customBinding> <binding name="onewayBinding"> <oneWay /> <tcpTransport /> </binding> </customBinding> </bindings>

Remember to use the same binding at the client also.

By default all calls from a client would be processed synchronously. If more than one call were made from a client, they would be queued up on the server. The proxy would also be blocked from closing until all the processing is completed.

To enable concurrent processing of messages at the service-

With the above custom binding, it will also ensure that messages are processed concurrently. Which means each request would be processed on a different thread. Or you could again use basicHttpBinding.
However if you are using NetTcpBinding or session shaped binding, you should mark your service concurrency mode as Multiple.

I’ll go through one such case where we had to rewrite a critical application while keeping access to the old system. We discovered that a lot of business functionality was kept in database triggers. There were many apps and I guess at that point someone decided to use triggers since they then needn’t touch any of the apps to add new features. You can read my take on business in database here.

We had decided to use DDD approach and this meant consolidating all those business rules in the trigger in their respective domains. The database being a common layer for both the applications, called for some strategy here.

The triggers couldn’t simply be disabled nor could we have them trigger when the new applications interacted with those underlying tables.

We need to restrict those triggers to only the old applications. The triggers will fire, no stopping that. But, we’ll stop the triggers body from continuing execution of the SQL. There are couple of ways of doing this.

1. Using App Name

   This is the least impact way of determining if the trigger needs to continue execution or return. Providing an app name in the connection string ;app=YourApplicationName, would make it available in your SQL session. I also make it a practice to include this as it helps in profiling your database more easily. In your SQL (Trigger) you can now check

   1	if (APP_NAME() = 'YourApplicationName') RETURN;

2. Using a column to track the transaction source

   Depending on your situation, this might be intrusive or acceptable. If this is a new column, you might want it to have a default value so that older applications can use that. You should set a specific value from your new applications for each transaction it does with these specific tables. Check for these values in the trigger and exit from executions. Of course the trigger would execute completely for transactions from your older applications. With this column you can also gain some insight in to who is transacting with which app. Be sure to check correctly in inserted or deleted special table depending on the operation that activates the trigger.

In both the above methods, there would be no change in the legacy applications.

BTW, many of the triggers were good candidates for domain events.

I have used both approaches and they have worked well for me. If there are other ways of doing this, let me know in your comments.

There are many situations where one needs to construct a complex object before consuming it. You might need to pass many arguments, set configurations and many other mandatory properties before the instance is ready for use. Passing parameters through constructors is a sure way of ensuring that your objects are always in a proper state when created. But for complex objects having everything through constructors can be a bit cumbersome and restrictive too in some cases.

I will not be taking you through building the standard builder pattern, but one which implements a fluent interface to build a product. It would not just be chaining of methods, but will also ensure that domain rules are met for the product.

A quick review of the main features of the builder pattern itself before we start addressing its quirks and the alternate approach.

A builder always returns a concrete product unlike factory or abstract factory which return abstract products.

A builder encapsulates the construction of an object (product). You would use one when the process of constructing an object is complex. The builder only defines the steps required to construct the object.

It does not enforce any order in which they should be called. The director has to know this and constructs the object through the builder.

While the builder is being built, it is in a mutable state.

Let us consider Account as our product which requires to be built.

1
2
3
4
5
6
7
8
9

class Account
{
    public int Number { get; internal set; }
    public string Type { get; internal set; }
    public IContact PrimaryContact { get; internal set; }
    public string HomeBranch { get; internal set; }
    // Optional
    public IEnumerable<IContact> OtherContacts { get; internal set; }
}

We have IContact just to spice up this product.

1
2
3

interface IContact
{
}

Let us also define a concrete for this interface

Our typical builder interface would look something like this

1
2
3
4
5
6
7
8

interface IAccountBuilder
{
    void SetNumber(int number);
    void SetType(string type);
    void AssignHomeBranch(string branchName);
    void RecordPrimaryContact(IContact primary);
    Account Build();
}

Most of the examples of the Builder out there would guide you to build a Director next, which takes in a Builder and returns the product. The director should now the order in which to call the methods in the builder. Most of the Directors do not accept any input from the user except the Builder itself. But if we need to accept inputs from the user (or program) to create our Product, the Builder would need to accept the inputs (as in our example) and the Director would also need to take in the inputs so that it could pass it over to the builder.

Instead we can have a Builder something like this

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

class AccountBuilder
{
    private Account _account = null;
    private List<IContact> Contacts {get; set;} = new List<IContact>();

    public AccountBuilder Create()
    {
        _account = new Account();
        _account.OtherContacts = Contacts;
        return this;
    }

    public AccountBuilder As(string type)
    {
        _account.Type = type;
        return this;
    }

    public AccountBuilder With(int number)
    {
        _account.Number = number;
        return this;
    }

    public AccountBuilder In(string branch)
    {
        _account.HomeBranch = branch;
        return this;
    }

    public AccountBuilder HavingAddress(IContact contact)
    {
        _account.PrimaryContact = contact;
        return this;
    }

    public AccountBuilder AddingOtherAddress(IContact contact)
    {
        Contacts.Add(contact);
        return this;
    }

    public Account Build()
    {
        return _account;
    }
}

We can now create an Account instance like this

1
2
3
4
5
6
7

AccountBuilder _builder = new AccountBuilder();
var account = _builder.Create()
                .As("Saving")
                .With(123)
                .HavingAddress(new Address("Sydney"))
                .In("Sydney")
                .Build();

The above Builder uses chaining of methods which constructs an Account class. Each method returns the same copy of its instance, allowing chaining of methods. Through this we can assign properties of the Account class. Finally, calling the Build() returns us the completed(hopefully!) Account class.

Even though the new builder is much easier to use, it comes with a lot of pitfalls. In order to use this interface, the developer would need to know the implementation details of each method. We cannot enforce assigning of mandatory properties. Knowing which are optional is also not intuitive. The client can also repeat assigning certain properties.

Let us try to remove some of the ways to fail by introducing certain guards. How can we ensure we always start with Create(), which allows for the instance of Account to be initialised.
We’ll make the constructor of AccountBuilder private and make the Create() a static method. The clients can now access AccountBuilder only through Create().

1
2
3
4
5
6
7
8
9
10

// In AccountBuilder
private AccountBuilder()
{ 
    var _account = new Account();
    _account.OtherContacts = Contacts; 
}
public static AccountBuilder Create()
{
    return new AccountBuilder();
}

Now our clients would use the builder like this

1
2
3
4
5
6

var account = AccountBuilder.Create()
                .As("Saving")
                .With(123)
                .HavingAddress(new Address("Sydney"))
                .In("Sydney")
                .Build();

Now the only saving grace is that we can at least ensure the client always gets an Account instance, even if they may not be completely constructed. I would still be hesitant to ship this to developers. What we want is to enforce an order of construction and guide them until all the rules have been met before the Account product can be returned.

For this we can look at I of the SOLID principles. Through Interface Segregation Principle, I’ll show how we can have a water tight builder.
We shall isolate each method in a separate interface. While at this, we’ll also determine what should be the next possible call(s) from this method. This can be done by returning the next permissible interface.
Let us see this in code to make it more clear.

Based on our methods we’ll define the following interfaces.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

interface IAccountType
{
IAccountNumber As(string type);
}
interface IAccountNumber
{
IPrimaryContact With(int number);
}
interface IPrimaryContact
{
IOtherContact HavingAddress(IContact contact);
}
interface IOtherContact
{
IOtherContact AddingOtherAddress(IContact contact);
IHomeBranch NoMoreAddress();
}
interface IHomeBranch
{
IAccountBuilder In(string branch);
}
interface IAccountBuilder
{
Account Build();
}

Each interface returns only the next available interface. This allows the user to progress only through the steps which we have defined. We can also allow the user to skip optional parameters (check IOtherContact). Only when the client reaches IAccountBuilder will they be able to access Build() which finally returns Account instance.

The account builder will now look like this. It will implement all of the above interfaces.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

class AccountBuilder : IAccountBuilder, IAccountNumber, IAccountType, 
IPrimaryContact, IHomeBranch, IOtherContact
{
    private Account _account = null;
    private List<IContact> Contacts {get; set;} = 
            new List<IContact>();
    private AccountBuilder()
    {
        var _account = new Account();
        _account.OtherContacts = Contacts; 
    }

    public static IAccountType Create() => new AccountBuilder();

    public IAccountNumber As(string type)
    {
        _account.Type = type;
        return this;
    }
    public IPrimaryContact With(int number)
    {
        _account.Number = number;
        return this;
    }
    public IOtherContact HavingAddress(IContact contact)
    {
        _account.PrimaryContact = contact;
        return this;
    }
    public IOtherContact AddingOtherAddress(IContact contact)
    {
        Contacts.Add(contact);
        return this;
    }
    public IHomeBranch NoMoreAddress()
    {
        return this;
    }
    public IAccountBuilder In(string branch)
    {
        _account.HomeBranch = branch;
        return this;
    }
    public Account Build()
    {
        return _account;
    }
}

And we use it similar to before

1
2
3
4
5
6
7

account = AccountBuilder.Create()
.As("Saving")
.With(123)
.HavingAddress(new Address("Sydney"))
.NoMoreAddress()
.In("Sydney 2000")
.Build();

With optional address

1
2
3
4
5
6
7
8

account = AccountBuilder.Create()
.As("Saving")
.With(123)
.HavingAddress(new Address("Sydney"))
.AddingOtherAddress(new Address("Katoomba"))
.NoMoreAddress()
.In("Sydney")
            .Build();

Doesn’t look much different, but the client cannot progress to the next method unless they go through the previous.
Depending on how you see this, this class is not immutable. If this is something you desire, then do not return the same instance of AccountBuilder, but a new one each time. You would need to maintain the state internally of AccountBuilder. Also create the Account only in the Build() method.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

class AccountBuilder : IAccountBuilder, IAccountNumber, IAccountType,
IPrimaryContact, IHomeBranch, IOtherContact
{
    // Maintain state
    private List<IContact> Contacts { get; set; } 
        = new List<IContact>();
    private string Type { get; set; }
    private int Number { get; set; }
    // protect instantiation
    private AccountBuilder()
    {}

    public static IAccountType Create() => new AccountBuilder();

    public IAccountNumber As(string type) => new AccountBuilder()
    {
        Type = type
    };

    public IPrimaryContact With(int number) => new AccountBuilder()
    {
        Type = this.Type,
        Number = number
    };

    public Account Build()
    {
        var account = new Account();
        account.Type = Type;
        account.Number = Number;
        return account;
    }

    /// rest of the implementation left out for brevity
}

I have left rest of the methods out in the above example, but you should be able to get an idea out of it. I now internally maintain state of the user’s inputs in the AccountBuilder‘s instance. When the Build() is called, I transfer all the values to the Account instance. BTW, I have used C# 6’s feature of expression-bodied functions.

I find builders very useful, especially when my domain is complex and need to control how the instance is created. With fluent interfacing and enforcing domain rules, it becomes easy for developers to create instances of your product. I find implementation of Builder this way more expressive and with more control.

Using a single if else or a small switch case has never been difficult. But if the options or decisions to make continues to grow, then you would soon end up with an unruly code base. You would very quickly lose loose coupling and with violation of Single Reponsibility Principle, there would be a huge risk of breaking existing code or introducing defects with newer requirements.

Chain of Responsibility (CoR) is very popular frameworks which employ it to process events or requests. One can write a single atomic unit of process and then chain them together to form a complex processing pipelines. OWIN is one such specification through which you can implement complex frameworks by chaining individual OWIN components together.

CoR provides a chance for more than one object to process the request. Every object in the chain can process the request or once the request has been processed by a suitable handler, it can return. The sender or the client needs to only know the initial handler or the base class to launch the request.

There is a special case which requires to be handled in CoR. Since each handler is chained like nodes in a linked list, the end of chain condition requires to be handled. We’ll review the options shortly.

Let us work with adding a new requirement to the existing application. A client requires to go through an approval process for Corporate accounts. Depending on the amount’s value a manager or director can approve the WithDrawal. Let us see how the solution looks without implementing it through the pattern. Let us pick up from where we left from our Decorator implementation.
Introduce a new Employee class which would provide us with a possible approver. The Approve method would determine if this employee can approve or not.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class Employee
{
    public Employee(string name, decimal approvalLimit)
    {
        Name = name;
        ApprovalLimit = approvalLimit;
    }

    public string Name { get; }

    private decimal ApprovalLimit { get; }

    public bool Approve(decimal amount)
    {
        if(amount < ApprovalLimit)
        {
            return true;
        }
        return false;
    }
}

In the Withdraw method, we now check through the list of approvers to determine if we can continue with the withdrawal.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

class Corporate : ITransaction
{
    private decimal _balance = 0;
    private decimal _overdraft = 0;
    const decimal overdraft_factor = 0.1m;
    // list of approvers
    List<Employee> approvers;
    public Corporate(decimal balance)
    {
        _balance = balance;
        Overdraft = _balance;
        Console.WriteLine("Opened corporate account with balance {0}", balance);
        Console.WriteLine("Overdraft stands at {0}", _overdraft);

        approvers = new List<Employee>
        {
            new Employee("Micky Manager", 1000),
            new Employee("Donald Director", 5000)
        };
    }

    // Omitted Deposit for brevity

    public void Withdraw(decimal amount)
    {
        bool amountProcessed = false;
        foreach (Employee approver in approvers)
        {
            amountProcessed = approver.Approve(amount);
            if (amountProcessed)
                break;
        }
        if(!amountProcessed)
        {
            Console.WriteLine("Amount {0} did not get approved", amount);
            return;
        }
        if (amount < Overdraft)
        {
            _balance -= amount;
            Overdraft = _balance;
            Console.WriteLine("Widthdrawn: {0} | New balance: {1} | Overdraft: {2}", amount, _balance, Overdraft);
            return;
        }
        Console.WriteLine("Could not withdraw. Current overdraft limit {0}", Overdraft);
    }
}

At this point there is no change in the client application.

1
2
3

IAccount account = new CreditAccount("C2102", AccountType.Corporate);
account.Deposit(1000);
account.Withdraw(1000);

In the Withdraw method we now iterate through the list of approvers. Why is this a cause of concern? This means that the algorithm for knowing how the approval process works is known to the caller. In this simple case it is iterating through a list of employees. It goes from one approver to the next until someone in the list approves or the list ends. CoR takes all these reponsibilities away from the caller, while also reducing coupling and granting more flexibility.
To move this to CoR implementation, we introduce a handler. The handler takes the responsibility of the action as well as promoting or delegating to the next handler if the current instance is unable to process.

Though it is not imperative to have an interface (I normally have just an abstract class), in this instance we would go with one.

1
2
3
4
5

interface IWithdrawHandler
{
    bool Approve(decimal amount);
    void SetNext(IWithdrawHandler next);
}

Implementing the interface we can get a common handler.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class WithdrawHandler : IWithdrawHandler
{
    private readonly Employee _approver;
    private IWithdrawHandler _next;
    public WithdrawHandler(Employee approver)
    {
        _approver = approver;
    }
    public bool Approve(decimal amount)
    {
        if (_approver.Approve(amount))
            return true;
        else
            return _next.Approve(amount);
    }

    public void SetNext(IWithdrawHandler next)
    {
        _next = next;
    }
}

The Corporate class can take in instance of IWithdrawHandler in its constructor.
In AccountBase where we were creating the instance of Corporate class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

class Corporate : ITransaction
{
    private decimal _balance = 0;
    private decimal _overdraft = 0;
    const decimal overdraft_factor = 0.1m;

    private readonly IWithdrawHandler _handler;
    //List<Employee> approvers;
    public Corporate(decimal balance, IWithdrawHandler handler)
    {
        _balance = balance;
        Overdraft = _balance;
        Console.WriteLine("Opened corporate account with balance {0}", balance);
        Console.WriteLine("Overdraft stands at {0}", _overdraft);
        _handler = handler;
    }

    public void Withdraw(decimal amount)
    {
        bool amountProcessed = _handler.Approve(amount);

        if(!amountProcessed)
        {
            Console.WriteLine("No approvers for amount {0}", amount);
            return;
        }
        if (amount < Overdraft)
        {
            _balance -= amount;
            Overdraft = _balance;
            Console.WriteLine("Widthdrawn: {0} | New balance: {1} | Overdraft: {2}", amount, _balance, Overdraft);
            return;
        }
        Console.WriteLine("Could not withdraw. Current overdraft limit {0}", Overdraft);
    }
}

abstract class AccountBase : IAccount
{
    protected ITransaction transactionImp;
    public AccountBase(string name, AccountType type)
    {
        Name = name;
        switch (type)
        {
            case AccountType.Personal:
                transactionImp = new AuditTransactionDecorator(new Personal(1000));
                break;
            case AccountType.Corporate:
                IWithdrawHandler micky = new WithdrawHandler(new Employee("Micky Manager", 500));
                IWithdrawHandler donald = new WithdrawHandler(new Employee("Donald Director", 1000));
                IWithdrawHandler scrooge = new WithdrawHandler(new Employee("Scrooge Owner", 1500));
                micky.SetNext(donald);
                donald.SetNext(scrooge);
                transactionImp = new AuditTransactionDecorator(
                    new NotifyTransactionDecorator(
                        new Corporate(5000, micky)));
                break;
            default:
                throw new NotImplementedException("Unknown account type");
        }
    }
    //...
    //...
    //...
}

There still is no change in the calling application, but only change is how the instance of Corporate is being created. When this is handled by DI or a factory, the change would be even less intrusive. One requirement of CoR is the handling of “end of chain” condition. What happens when we reach the last handler (scrooge here) and is unable to approve? In this case NullReferenceException is thrown. This might be an acceptable behaviour, though you might want to throw a custom exception. The client in this case should be prepared to take a corrective action. Another way is to have the last handler special such that it knows not to try and promote to next handler, but always returns. Or you could have a special handler which is meant to handler ‘end of chain’ event. This is akin to a Null Object where it has a default implementation.

EF is good enough to provide us with sufficient mapping powers to use the data model as our business model. Also I would want to keep things simple and direct by using the same model for both domain as well as EF. However, this brings up a few challenges.

If you need a fully encapsulated domain, you would probably want to expose your collections as IEnumerable<T>. But, you cannot have IEnumerable<T> for your collection and map to EF. It requires the collection to be of type ICollection<T>. But this would allow direct access to manipulate the collection through its Add, Remove methods. Your domain is not completely encapsulated. You can get around this limitation and use IEnumerable<T> in your model so that it is protected by your domain rules, but you would have to load the collection manually through your repository or factory in to the domain model. You would need to track the changes yourself and let EF know at the time of persisting by attaching each object from the collection back to EF and set with the relevant EntityState. This is needed since you could not have mapped an association in EF as your ICollection<T> backing member was private.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public class Student
{
    public string Name { get; private set; }

    private List<Course> _courses;
    public IEnumerable<Course> Courses { get { return _courses; } }

    public void AssignCourses(IEnumerable<Course> courses)
    {
        _courses = new List<Course>(courses);
    }

    public Student(string name)
    {
        Name = name;
    }
    private Student() { }
}

public class StudentRepository
{
    public Student Get(string name)
    {
        var student = context.Students.FirstOrDefault(c => c.Name == name);
        var courses = context.Courses.Where(c => c.Name == name).AsEnumerable();
        student.AssignCourses(courses);
        return student;
    }
}

Another approach would be for you to map your private properties or members. This is a bit more involved than the previous method, but you can take advantage of EF while loading objects. In this article, mapping to non-public member shows one way how this can be achieved. As the article explains, this would not be a pure POCO since it contains knowledge of configuration for persistence. But I like this approach as it is simple and non-intrusive to the actual behaviour of the POCO itself.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public partial class Account
{
    public int Id { get; private set; }

    public string Name { get; private set; }

    private string Code { get; set; }
}

public partial class Account
{
    public class EFStorageExpression
    {
        public static readonly Expression<Func<Account, string>>
            CodeAccessor = a => a.Code;
    }
}

You can then map it as follows under EntityTypeConfiguration<Account>

1

Property(Account.EFStorageExpression.CodeAccessor)

The reason I stated this as complicated was that, sometimes it does not end with us just being able to map the entity and load it. We would also need to query using the private properties. If a private field is holding a collection, then there might be more reasons to filter on them. You would still be able to Include them to eager load them. You would then need to go through the Expression which you have exposed.

Let us see how we can query the for Account.

1

var account = context.Accounts.Where(a => a.Id == id).FirstOrDefault();

This would infact load the value for the property Code. But what if you need to filter on Code? All we have is the Expression<Func<Account, string>> pointing to Code property, but we require an Expression<Func<Account, bool>> which should be passed as the Where clause. For this we’ll need to build an Expression which represent our filter.

1
2
3
4
5
6
7
8
9
10
11

static Expression<Func<Account, bool>> SearchCode(string code)
{
    ParameterExpression param = Expression.Parameter(typeof(Account));
    var codeExp = Expression.Constant(code);

    var invokedExpr = Expression.Invoke(Account.EFStorageExpression.CodeAccessor,
            param);
    var searchCodeExp = Expression.Equal(invokedExpr, codeExp);
    // a => a.Code == code
    return Expression.Lambda<Func<Account, bool>>(searchCodeExp, param);
}

Using the above, our search on Code can be done like this.

1

var account = context.Accounts.Where(SearchCode("A001")).FirstOrDefault();

But during runtime, this fails miserably throwing an exception

Message=The LINQ expression node type ‘Invoke’ is not supported in LINQ to Entities.

The problem is LINQ to Entities does not support Invocation of expressions. This works fine with LINQ to Objects and LINQ to SQL, but not with EF. You would need to use an ExpressionVisitor to rewrite the tree.
Or use LinqKit as I do here. This can be downloaded from Nuget. With this you can use your Expressions with EF.

The same query above after LinqKit looks as below.

1
2

var account = context.Accounts.AsExpandable().
    Where(SearchCode("A000001")).FirstOrDefault();

The only addition was AsExpandable() extension before calling your custom expression. Everything works like a charm.

You can now hide your data and also make use of EF without adding much gunk to your model.

This intrigued me. But before jumping and investing in a standing desk, I had to test it out first. Will I like standing and working? These desks don’t come cheap. Would I be really using it and find it comfortable? I knew it would be very difficult to judge any immediate health benefits by using the desk. I am not sure how this can be determined after continued use also. But what I needed to know was how comfortable would it be in using it.

I scoured the internet and came across a few hacks and Ikea hacks. I even came up with a design to build a frame using PVC pipes to support a laptop and a keyboard, when placed on a table. All required new material purchases, time and effort. Then it hit upon me to simply use cardboard boxes already lying around which were sturdy enough to support a laptop and also high enough to provide ergonomic viewing of the screen. I used shorter box to place my external keyboard and mouse on. This way my forearm was comfortable and parallel to the floor. With this setup I was able to very comfortably work standing on my laptop without any strain or discomfort. I could easily stand and work for 2 hours at a stretch. And all for zilch. This is what I would call a good POC.

I had a similar setup at office and tried out standing and working for more than a month. It was much easier at work since I would use my desktop while sitting and switch over to laptop while standing. I just had to clear the boxes whenever I felt like reclaiming my desk space.

Conclusion. Standing and working rocks. I absolutely loved it. One thing I observe is that each time I switch to standing mode, it gives me a fresh boost of energy and focus. It definitely gives you a psychological advantage.

Now for those who plan to research further, there are basically 2 categories of standing desks. One which sits on top of your existing desk. This involves least rearrangement of your existing furniture and you could get to use your existing cubicle desk or table. The other variety is where the entire desk moves up or down with the help of a motor. These type of desks are more expensive, but also offer you greater flexibility and more usable space.

When I was ready for a more serious desk, thanks to my company, I settled down with a brand new VERIDESK PRO.

It is very convenient to transform it from sitting to standing and vise versa. You can easily pull up the desk using the hand slots and lock it at any height. It does use up some desk space and you might have to rearrange your desk items to suit the new furniture.

I also love using multiple monitors while working. This desk accommodates two large ones very easily. You also can keep few small items while using it in standing mode.

Taking it down to sit is even more easier. But I have to warn you! Always ensure there is nothing under the lower platform. It is going to crush it. Be it cables, pen or ear phones. Yes, during the first lowering excersice I crushed my favourite ear phones. Sigh! Now I always look underneath to ensure nothing is going to get crushed. I also stop at the lowest possible level and pull out the keyboard and mouse cables out of the way before lowering it all the way down. You need to push down until it clicks to lock in.

Motorised desks obviously won’t have this drawback of having to clear or rearrange your desk. Whether down or up, it is the same.

Whichever standing desk you choose, here the end is more important than the means.

For last couple of days I have been exploring TPL Dataflow in seeing how it can reduce complexity of parallel processing by alleviating callbacks and synchronizations such as locks and sharing data. And I am loving it. I am still exploring this library and the resources and documentations on this seem a bit scarce as of now. I feel there are not enough developers using it as they are not aware or the design pattern is unfamiliar.

How can we use Dataflow to handle events?

There was a particular feature which caught my attention since my last 2 articles were based on events, I set out to implement a solution to handle events by using Dataflow. For those of you who are exploring DDD, I recommend taking a look at Domain Events which helps you keep the domain completely encapsulated. I like the idea here of exposing events as an object instead of a delegate. The immediate benefit I see is that the domain class no longer needs to hold a reference to the handler and the handlers need not explicitly unsubscribe from the events. These were few of the drawback which I had stated earlier by using delegate based event and this addresses them nicely.

TPL Dataflow is built on top of Task Parallel Library and so with it brings all the familiar support for tasks and asynchronous programming. It is not distributed with the .NET framework and needs to be installed through NuGet. Look for Microsoft.Tpl.Dataflow and you should have System.Threading.Tasks.Dataflow.dll when installed.

Quick Intro

To get started, Dataflow provides us blocks with pipes through which data can be processed or just flow. A block can either receive (ITargetBlock<T>) or offer data (ISourceBlock<T>) or do both when combined. The data can be processed by the block or simply transferred. You can push data to a block (Post(input)) and get output from it (Receive). You can connect two or more blocks together by linking them together (LinkTo(ITargetBlock)). That’s where the analogy of pipes comes in. Once you have linked the blocks and send data to the top most block, you need not worry about moving data. The linking would take care of propagating data from one block to another. You can instruct a block to stop accepting input anytime.
There are different blocks readily made available and one could create custom blocks too. You can find more information from Microsoft’s Introduction to TPL Dataflow.

In this article I’ll hit the ground running with Dataflow by using it to handle my domain events. I would be building this on top of my earlier simple domain example used here and here. I would be borrowing the idea of domain event here and represent it explicitly through an instance.

Domain Event Interface

1
2
3
4

public interface IDomainEvent
{
    DateTime EventOccurred { get; }
}

Define my event for product added.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class ProductAddedEvent : IDomainEvent
{
    public DateTime EventOccurred
    {
        get; private set;
    }

    public Product Product { get; private set; }

    public ProductAddedEvent(Product product)
    {
        EventOccurred = DateTime.Now;
        Product = product;
    }
}

The event would now be raised by the domain object Product

1
2
3
4
5
6
7
8
9
10
11

public Product(IBroadcaster mediator)
{
    _mediator = mediator;
}

public void Add(string name, int quantity)
{
    Name = name;
    Quantity = quantity;
    _mediator.Post(new ProductAddedEvent(this));
}

As you can see, the domain no longer raises an event, but sends the change in state through an object instance of ProductAddedEvent. Also there are no static calls here to raise the event, but through an injected instance of IBroadcaster.

1
2
3
4

public interface IBroadcaster
{
    void Post<T>(T args) where T : IDomainEvent;
}

All those interested in subscribing to any type of IDomainEvent would do through a concrete instance of ISubscriber.

1
2
3
4
5
6
7

public interface ISubscriber
{
    IDisposable Subscribe<T>(Action<T> action)
        where T : IDomainEvent;

    void UnSubscribe(IDisposable obj);
}

Ok. So how do we link all this up and where does Dataflow fit in? Under Dataflow we have a BroadcastBlock<T> concrete implementation. Its sole mission is to send a copy of every message published to all linked targets. Optionally you can even issue a cloning function Func<T,T> on how that copy would be offered to the targets.

We implement both the interfaces here to manage subscription and posting of messages.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class EventMediator : ISubscriber, IBroadcaster
{
    private readonly BroadcastBlock<IDomainEvent> broadcast =
        new BroadcastBlock<IDomainEvent>(args => args);

    public void Post<T>(T args)
        where T : IDomainEvent
    {
        broadcast.Post(args);
    }

    public IDisposable Subscribe<T>(Action<T> action)
        where T : IDomainEvent
    {
        var handler = new ActionBlock<IDomainEvent>(
            args => action((T)args));

        return broadcast.LinkTo(handler,
            e => e.GetType() == typeof(T));
    }

    public void UnSubscribe(IDisposable obj)
    {
        obj.Dispose();
    }
}

Event handlers can subscribe to the events they are interested in. The message would be passed only to those handlers which satisfy the filter condition.
Another beauty is anytime a handler can unlink by calling UnSubscribe which just disposes off the IDisposable object returned by the LinkTo call. This would internally unlink and stop sending future messages to that handler.

That’s it. Now we write the handler and subscribe.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class CheckStock : IDisposable
{
    private IDisposable _subscription;
    public CheckStock(ISubscriber subscriber)
    {
        _subscription = subscriber.Subscribe<ProductAddedEvent>
            (m => Handler(m));
    }

    private void Handler(ProductAddedEvent args)
    {
        Console.WriteLine("Received by CheckStock,
            event at {0}", args.EventOccurred);
        Console.WriteLine("Checking stock for {0} ",
            args.Product.Name);
    }

    public void Dispose()
    {
        _subscription.Dispose();
    }
}

Stitching them up together below we can see them in action.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

var mediator = new EventMediator();
// subscribers
var stockChecker = new CheckStock(mediator);
var notify = new SendNotification(mediator);

// add an inline handler
var adHoc = mediator.Subscribe<ProductAddedEvent>(
    (m) => 
    { Console.WriteLine("This is an inline process for {0}",
    m.Product.Name); });

var product = new Product(mediator);
product.Add("Cutting edge", 10);

//notify.Dispose();
// Unsubscribe one of them
mediator.UnSubscribe(adHoc);
product = new Product(mediator);
product.Add("Bleeding edge", 10);

What we now have is completely unit testable and injectable. Those adhering to DDD would have a fully encapsulated domain. Since the Subscribe takes in an Action<T>, send any action which you can assert when the event is raised.

If there are many events in a domain, we can define new type implementing IDomainEvent

1

public class ProductDeletedEvent : IDomainEvent

Assign a handler for the new event and subscribe

1

mediator.Subscribe<ProductDeletedEvent>(m => Handler(m));

The above handlers would run as concurrent operations. You can send message to as many handlers as required while still being able to maintain throughput. Dataflow allows you to throttle the processing or buffer your messages. Like we have multiple consumers registered with EventMediator, we can have multiple producers sending data through the same instance of EventMediator.

In the previous post we saw how to make use of events to extend functionality. We also saw that the execution of the handlers were blocking in nature. The execution was synchronous. There might be a real benefit if the handlers were executed asynchronously without blocking the main thread. Please note that I stressed on might. You have to choose carefully if your operations requires parallelism, because this will complicate your application and would take more resources without any benefit in return. If you foresee many handlers listening to an event, this might give you the desired throughput by offloading them to background threads. If you are making the call from a UI thread, it would also be beneficial to free up the UI thread.
Since the events are handled by delegates we can leverage asynchronous methods calls. You can find more information of calling methods asynchronously here as of this writing.

There are a few things we have to consider and be cautious while dealing with events asynchronously. Events return void by default. When you use the generic delegates (EventHandler / EventHandler<EventArgs>) they always return void. If you use custom delegates which return value with your events, it can become awkward to deal with them when they have multiple handlers attached to them. I am not saying it is not possible, just difficult. You should be able to correlate each handlers return value, if not you would end up only with the value from the last handler’s result. Then again if you require return value from your events, then you might nned to use something other than events.

The only thing the subject needs to wait for is until all the handlers complete executing. If the thread (main or foreground) from which the event handlers were invoked exits before the handlers return, which would be running on the background thread, then they would be abruptly terminated. You would also only know if there were any exceptions in any of the handlers when you call the EndInvoke of the delegate.

Asynchronous Programming Pattern (APM) is now obsolete in favour of Task-based Asynchronous Pattern (TAP) and so is Event-Based Asynchronous Pattern (EAP). Calling of Begin method, dealing with IAsynResult and calling of End was not easy to implement and for a client consuming it, the very least, cumbersome.

We can now use Task.Factory.FromAsync which makes it easy to deal with APM calls by returning a Task. One of its overloads takes the Begin/End pair and while taking any additional arguments that gets passed to these methods. If you find the overloads lacking, then you can provide one of your own wrapper using TaskCompletionSource internally similar to FromAsync.

For those projects which cannot yet take advantage of TAP, I recommend using callback method when the call completes as described in MSDN. Through this one can handle multiple handlers since the callback would provide you with a unique IAsyncResult so that you don’t need to keep track of it. It provides the most flexibility and least blocking.

Ok, heading back to implement our asynchronous event handlers, we’ll see that there are not much changes that need to be done to the synchronous implementation. We would be receiving a Task for each Add. Add method signature would now be look as below

1

public async Task AddAsync(string name, int quantity)

Notice we are returning a Task and also marked it as async. Also changed the method name to reflect this as per the conventions.
One for all, all for one. If one method is async in a chain of calls, then it is best to have all the methods up the order as async-await.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

public class ProductAsyncTask
{
    public event EventHandler<ProductAsyncTaskEventArgs> Saved;

    // simulate data store
    private readonly IDictionary<string, ProductAsyncTask> _productRepository;

    public ProductAsyncTask()
    {
        _productRepository = new Dictionary<string, ProductAsyncTask>();
    }

    public string Name { get; set; }
    public int Quantity { get; set; }

    public async Task AddAsync(string name, int quantity)
    {
        if (_productRepository.ContainsKey(name))
        {
            _productRepository[name].Quantity = quantity;
            Console.WriteLine("Thread# {2}: {0} quantity updated to {1}",
                name, quantity, Thread.CurrentThread.ManagedThreadId);
            // return a completed task
            await Task.CompletedTask;
            return;
        }
        var p = new ProductAsyncTask() { Name = name, Quantity = quantity };
        _productRepository.Add(name, p);
        Console.WriteLine("Thread# {1}: New Product added - {0} ",
            name, Thread.CurrentThread.ManagedThreadId);
        // wait without blocking the thread
        await OnSaved(p);
        Console.WriteLine("Thread# {1}: Completed add for {0}",
            name, Thread.CurrentThread.ManagedThreadId);
    }

    protected async virtual Task OnSaved(ProductAsyncTask p)
    {
        var multiDels = Saved as EventHandler<ProductAsyncTaskEventArgs>;
        if (multiDels == null)
        {
            await Task.CompletedTask;
            return;
        }
        // list of event subscribers
        Delegate[] delList = multiDels.GetInvocationList();
        Task[] tasks = new Task[delList.Length];
        for (int i = 0; i < delList.Length; i++)
        {
            EventHandler<ProductAsyncTaskEventArgs> e = 
                delList[i] as EventHandler<ProductAsyncTaskEventArgs>;
            Task t = Task.Factory.FromAsync(
                e.BeginInvoke, e.EndInvoke, this,
                new ProductAsyncTaskEventArgs(p), null);
            tasks[i] = t;
        }
        await Task.WhenAll(tasks);
    }
}

Nothing much has changed inside the AddSync method. We are now awaiting on task or returning a completed task if there is nothing to continue for.
Inside OnSaved we see a little bit more action. We are now getting a list of delegates from the MulticastDelegate and use Task.Factory.FromAsync to create a Task for async call of each delegate. If we would have created a Task using Task.Factory.StartNew or Task.Run and made an Invoke of each delegate, the final outcome would be the same. But, this would have blocked each thread on the thread pool until completion since the task would run synchronously. In FromSync, the EndInvoke call would signal the completion and the thread would not be blocked.

The client application

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

var productTask = new ProductAsyncTask();
productTask.Saved += handler1.SendMail;
productTask.Saved += handler2.DoCall;
productTask.Saved += handler3.Audit;

var t1 = productTask.AddAsync("Cadbury classic", 10);
var t2 = productTask.AddAsync("Lindt Dark 80%", 10);
var t3 = productTask.AddAsync("Mars", 10);
var t4 = productTask.AddAsync("Cadbury classic", 10);
Console.WriteLine("Doing some other work here...");
try
{
    Task.WaitAll(t1, t2, t3, t4);
}
catch (AggregateException ae)
{
    foreach (var e in ae.InnerExceptions)
    {
        Console.WriteLine(e.Message);
    }
}
// unregister
productTask.Saved -= handler1.SendMail;
productTask.Saved -= handler2.DoCall;
productTask.Saved -= handler3.Audit;

I have not including any error handling, but since we have a Task returned, we can follow its exception handling pattern. You can have a continuation task on fault or catch the exceptions closest to its source. Also if the subject is long lived, remember to un-register the handlers.

So we have seen how we can relatively easily make our event handlers run asynchronously using TAP.

Event - a notification of a an occurrence or incidence, in programming terms, almost always in the past. Events are not always intuitive or easy to follow since they jump out of the natural control flow.
If we consider approaches to extend functionality without uglifying your class immediate thought goes to Dependency Injection. Whether it is a service or a Decorator, they now become the dependencies of your class, albeit through Inversion of Control. I am not saying this is bad, but raising events do not get a fair consideration.

Yet in so many cases they present as a great choice to extend functionality by reacting to them and even pass data out through to consuming clients. Yes, they can serve as a great vehicle to send data out. If you consider a method which returns void, but raises an event, then even though returning void is able to communicate or send out data through events. Neat.

Here I would be discussing on how to leverage events and improve code instead of delving into semantics of events and delegates in the DotNet framework. I intend this post to serves as a food for thought on using events to decouple behaviour.
Events enable loose coupling and promote separation of concerns. You can delegate (no pun intended) all external processing to the event handlers such as logging, notifications or calls to other services. The event could have multiple subscribers to it. It is a good way to update a subject’s dependents. As you can see, events need not be restricted to UI programming, but are also equally suitable for business components.
Let is consider a product domain. I’ll keep the domain logic simple and mundane so that we can focus on events and its usage. We wish to raise an event for each new product that gets added. The handlers(subscribers) who are interested in this event can then react to this.

Product(Subject)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

public class ProductSync
{
    public event EventHandler<ProductSyncEventArgs> Saved;

    // simulate data store
    private readonly IDictionary<string, ProductSync> _productRepository;

    public ProductSync()
    {
        _productRepository = new Dictionary<string, ProductSync>();
    }

    public string Name { get; set; }

    public int Quantity { get; set; }

    public void Add(string name, int quantity)
    {
        if (_productRepository.ContainsKey(name))
        {
            _productRepository[name].Quantity = quantity;
            Console.WriteLine("Thread# {2}: {0} quantity updated to {1}",
                name, quantity, Thread.CurrentThread.ManagedThreadId);
            // no event will be raised here
            return;
        }
        var p = new ProductSync() { Name = name, Quantity = quantity };
        _productRepository.Add(name, p);
        Console.WriteLine("Thread# {1}: New Product added - {0} ",
            name, Thread.CurrentThread.ManagedThreadId);
        OnSaved(p); // event raised
        Console.WriteLine("Thread# {1}: Completed add for {0}",
            name, Thread.CurrentThread.ManagedThreadId);
    }

    protected virtual void OnSaved(ProductSync p)
    {
        // check if we have any handlers listening
        // and call them. Below is a short hand to do that.
        (Saved as EventHandler<ProductSyncEventArgs>)?.Invoke(this, new ProductSyncEventArgs(p));
    }
}

public class ProductSyncEventArgs : EventArgs
{
    public ProductSyncEventArgs(ProductSync product)
    {
        Product = product;
    }
    public ProductSync Product { get; private set; }
}

I have deliberately appended Sync to the name. This is to highlight that event handlers subscribing to an event are invoked synchronously. The execution path does jump from one method to another, but the calls are blocking. I have included the thread id to show where the publishers and the subscribers are executing. This is important so that we do not have any misleading assumptions since the execution flow passes to the handlers. We also have a class ProductSyncEventArgs which inherits from EventArgs. This is a standard approach to pass arguments through events within DotNet.

Let us create a few subscribers or event handlers which need to do some work when event is raised.

Handlers (Subscribers)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

public class NotifyHandler
{
    readonly ConsoleWriter cw;
    public NotifyHandler()
    {
        cw = new ConsoleWriter();
    }
    public void SendMail(object source, ProductSyncEventArgs e)
    {
        Thread.Sleep(1000);
        cw.Write("Thread# {1}: Sending email for product {0}",
            ConsoleColor.Red, e.Product.Name,
            Thread.CurrentThread.ManagedThreadId.ToString());
    }
}

public class ExternalCallHandler
{
    readonly ConsoleWriter cw;
    public ExternalCallHandler()
    {
        cw = new ConsoleWriter();
    }
    public void DoCall(object source, ProductSyncEventArgs e)
    {
        Thread.Sleep(1000);
        cw.Write("Thread# {1}: New note added for {0}",
            ConsoleColor.Green, e.Product.Name,
            Thread.CurrentThread.ManagedThreadId.ToString());
    }
}

public class QuantityAuditHandler
{
    readonly ConsoleWriter cw;
    public QuantityAuditHandler()
    {
        cw = new ConsoleWriter();
    }
    public void Audit(object source, ProductSyncEventArgs e)
    {
        Thread.Sleep(1000);
        cw.Write("Thread# {2}: Auditing for {1}. Quantity: {0}",                
            ConsoleColor.Yellow, e.Product.Quantity.ToString(), e.Product.Name,        
            Thread.CurrentThread.ManagedThreadId.ToString());
    }
}

//helper to colour code console outputs
public class ConsoleWriter
{
    public void Write(string message, ConsoleColor colour, params string[] args)
    {
        Console.ForegroundColor = colour;
        Console.WriteLine(message, args);
        Console.ResetColor();
    }
}

The implementations are self-explanatory. I have added Thread.Sleep to simulate a load and helper class to output colour coded text to indicate some behaviour.

Application (Client)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Program
{
    static void Main(string[] args)
    {
        var handler1 = new NotifyHandler();
        var handler2 = new ExternalCallHandler();
        var handler3 = new QuantityAuditHandler();

        var product = new ProductSync();
        // registering handlers
        product.Saved += handler1.SendMail;
        product.Saved += handler2.DoCall;
        product.Saved += handler3.Audit;

        product.Add("Cadbury classic", 10);
        product.Add("Lindt Dark 80%", 10);
        product.Add("Mars", 10);
        product.Add("Cadbury classic", 10);
        // unregistering handlers
        product.Saved -= handler1.SendMail;
        product.Saved -= handler2.DoCall;
        product.Saved -= handler3.Audit;
    }

When you run the program you get the below output. It clearly shows the synchronous execution and how the Add call is blocked until all the handlers have not returned.

When a product is now added there can be other actions executed without having to inject external dependencies to the Product class. I would however like to point out there are a few draw backs in implementing events this way. Astute readers would have already realised that what we have seen is DotNet’s inbuilt implementation of Observer pattern and most of these drawbacks are inherit to Observer pattern.

• Multiple subscribers and publishers make it difficult to maintain and understand code.
• Subscriber and publishers need to know each other. This tight coupling will not allow each to vary independently.
• The publisher holds strong references of each observer. This might create memory leaks when the subscriber does not de-register themselves.

Here I would not go into addressing each of these issues, but these could be solved using Mediator pattern or Event Aggregate pattern. Again a warning, both these patterns at first glance might seem interchangeable or have the same intent, but they are not. Mediator helps in communicating between unrelated objects, which require co-ordinations. It is not mandatory to use Event type with in Mediator. You would see behaviour inside Mediator. Event Aggregators as the name suggests deal only in maintaining subscriptions and publishing of events. Once again it need not be done using Event type. You can also manage the references of subscribers to avoid memory leaks. Of course all this would mean more work upfront.
Well, like I had mentioned, this post was supposed to be a food for thought and use of events in modelling business logic.
In a continuing post I’ll explore how we can call the event handlers asynchronously.

Do let me know your thoughts through comments on how you have used events in your business layers?

I always have SQL profiler open when programming EF just to make sure EF is doing the right thing. With EF6 onwards you could also use context.Database.Log to review what EF does underneath.

When I ran my application, I noticed a very visible lag in performance. The table I was working on was very large, but the query was returning only one row, so the impact really stood out. But I knew that the query would not take that long to execute otherwise. I looked at the query in the profiler and at first glance it looked normal. The query was as simple as it could be. I copied it and ran it under query analyser. The query once again took perceivably longer time to finish. This told me it was not EF alone responsible. Looked at the execution plan, it did not look normal. There was an index scan instead of seek and a lot of parallelism thrown in. Then I took a closer look at the query plan and voila the reason for the slow performance became obvious.

Entity Framework defaults to Unicode. This is very easy to overlook and under certain EF strategies and configurations it can really hit your SQL performance. Note, this has nothing to do with EF itself, but how SQL server prepares and executes the query provided by EF.

Let me illustrate with an example.
Below is my sample database. Product with many sales.

Below is how the mapping is defined.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public virtual ICollection<Sale> Sales { get; set; }
}

public class Sale
{
    public int Id { get; set; }
    public int ProdId { get; set; }
    public DateTime SaleDate { get; set; }
    public virtual Product Product { get; set; }
}

public class ProductContext : DbContext
{
    public ProductContext()
        : base("TestDb")
    {
        Database.SetInitializer<ProductContext>(null);
    }

    public DbSet<Product> Products { get; set; }

    public DbSet<Sale> Sales { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Product>().HasKey(p => p.Id)
            .Property(p => p.Id)
            .HasColumnName("ProdId")
            .HasDatabaseGeneratedOption(System.ComponentModel.DataAnnotations
                .Schema.DatabaseGeneratedOption.Identity);

        modelBuilder.Entity<Product>()
            .HasMany(s => s.Sales)
            .WithOptional();

        modelBuilder.Entity<Sale>().HasKey(s => s.Id)
            .Property(s => s.Id)
            .HasColumnName("SaleId")
            .HasDatabaseGeneratedOption(System.ComponentModel.DataAnnotations
                .Schema.DatabaseGeneratedOption.Identity);

        modelBuilder.Entity<Sale>()
            .Property(s => s.ProdId)
            .HasColumnName("ProdId");

        modelBuilder.Entity<Sale>()
            .HasRequired(p => p.Product)
            .WithMany(s => s.Sales)
            .HasForeignKey(s => s.ProdId);
    }
}

Below is how EF has interpreted the mapping.

Let us query for product by name.

1

var prods = prodContext.Products.Where(p => p.Name == "p3").ToList();

EF generates the below query.

1
2
3

SELECT [Extent1].[ProdId] AS [ProdId], [Extent1].[Name] AS [Name]
FROM [dbo].[Products] AS [Extent1]
WHERE N'p3' = [Extent1].[Name]

Pay attention to the Unicode conversion against the search value(N‘p3’). Below is the query plan.

Notice how SQL is converting each row to Unicode before the search. This is what is killing your queries performance.
The fix is simple. Just let EF know that the column you are mapping to is not Unicode or is VARCHAR. This will allow EF to issue queries without the conversion.
Add mapping details for the Name property instead of mapping through convention. Specify either Not Unicode or the column type.

1
2
3
4

modelBuilder.Entity<Product>()
    .Property(p => p.Name)
    .IsUnicode(false);
    //.HasColumnType("varchar");

If you approach using model first or code first without an existing database, you would not get into this problem since EF would create the database for you. This is also true if you reverse engineer your database to get your edmx generated. The tool would include the correct datatypes while mapping.

Now this should help me remember and hopefully help others too from stumbling.

Authorisation is one of the most intertwined aspect in an application. We find it the most difficult part to isolate its implementations from rest of the logic. We can overcome partly syntactically through declarative sugar, but for more complex evaluations we might have to go inline. But the application still needs to continue checking the validity of the user.

The best thing that happened in security since .NET version 4.5 is that Claims became the base for all identity based security and with it we also saw ways through which we could externalise the authorisation logic (and also building of claims). A claim is statement or declaration made about oneself or others. When a user tries to claim access to any resource, the authorisation process assess if they trust the issuer of the claim and evaluates the claim.

In claim based authorisation the applications need not authenticate individuals and find out about the user. It is presented with claims by the user and the application just uses it to determine if they indeed have the right claim to continue. Now the application is undisturbed (decoupled) by the ever changing roles of a user or whether it has to accommodate any changed roles. As long as the user presents it with the right claims they get access.

Using claims not just simplifies authorisation, but you can use it to add other important facts about the user. During authentication, we could query multiple systems or specific sources which the application is more interested in and build the claim for the user. These could be email addresses, roles, position, mode of transport, dietary preferences anything which makes sense and need to share that information with applications. You can already see if used correctly how it would make authorisation and personalisation mush more easier in applications.

Enough with the introductions already! Windows Identity Foundation has now been merged with .NET Framework and we have access to default implementations of ClaimsAuthorizationManager. We can override this programmatically by using IdentityConfiguration or through application configuration file.

Through configuration:

1
2
3
4
5

<system.identityModel>
    <identityConfiguration>
      <claimsAuthorizationManager type="CustomAuthorisationManager"/>
    </identityConfiguration>
</system.identityModel>

One limitation which it presents is that the custom type reference which we provide through configuration must have a 0 argument constructor. Which means we cannot specify any dependencies through the constructor.

This can however be overcome through code. We can register for the event FederationConfigurationCreated and when the FederationConfiguration is initialised, this event is raised where we can then modify the configuration to assign our own ClaimsAuthorizationManager.

Through code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

namespace ClaimsAwareApp
{
    class App
    {
        static void Main(string[] args)
        {
            FederatedAuthentication.FederationConfigurationCreated += 
                FederatedAuthentication_FederationConfigurationCreated;

            //declarative
            DoAction();

            // inline
            var cuthmgr = FederatedAuthentication.FederationConfiguration
                            .IdentityConfiguration.ClaimsAuthorizationManager;
            var authContext = 
            new AuthorizationContext(ClaimsPrincipal.Current, "SomeResource", "Execute");
            if (cuthmgr.CheckAccess(authContext))
                Console.WriteLine("DoAction");
        }

        [ClaimsPrincipalPermission(
            SecurityAction.Demand,
            Operation = "Execute",
            Resource = "SomeResource")]
        static void DoAction()
        {

        }

        private static void FederatedAuthentication_FederationConfigurationCreated(object sender,
                            FederationConfigurationCreatedEventArgs e)
        {
            DependencyFactory factory = new DependencyFactory();
            e.FederationConfiguration.IdentityConfiguration.ClaimsAuthorizationManager = 
                                        new CustomClaimAuthorisation(factory);
            //e.FederationConfiguration.IdentityConfiguration.ClaimsAuthenticationManager
            //                          = new ClaimsAuthenticationManager();
        }
    }

    class CustomClaimAuthorisation : ClaimsAuthorizationManager
    {
        private readonly DependencyFactory factory;
        public CustomClaimAuthorisation(DependencyFactory factory)
        {
            this.factory = factory;
        }

        public override bool CheckAccess(AuthorizationContext context)
        {
            // Get instance from factory
            using (var store = factory.GetStore())
            {
                // Do your authorisation
                return base.CheckAccess(context);
            }
        }
    }
    class DependencyFactory
    {
        public MyStore GetStore()
        {
            return new MyStore();
        }
    }

    class MyStore : IDisposable
    {
        public void Dispose()
        {
            // clean up
        }
    }
}

Few points to note!

You need to have system.identityModel in your configSections of your configuration file.

1
2
3
4
5
6
7
8

<configuration>
  <configSections>
    <section name="system.identityModel"
             type="System.IdentityModel.Configuration.SystemIdentityModelSection,
                    System.IdentityModel, Version=4.0.0.0,
                    Culture=neutral, PublicKeyToken=B77A5C561934E089" />
  </configSections>
</configuration>

Without the above entry you would run into the below exception.

Message=ID7027: Could not load the identity configuration because no <system.identityModel> configuration section was found.

I think this config section is mandatory to get access to instance of FederationConfiguration. I anyway have not found a work around for this.

Also note that FederationConfiguration is created as a singleton and you would always get the same instance of ClaimsAuthorizationManager or ClaimsAuthenticationManager. So take care how you manage the lifetime of the objects which you inject inside of these instances. If you need to dispose them after each call, I recommend inject Factory instance instead of the actual concrete instance. This way you can dispose of the concretes and have the factory provide you with a new instance on each call to CheckAccess in the case of authorisation.

Of course for a web application, one should register the FederationConfigurationCreated event under global.asax App start.

One cannot always start by applying design patterns with a new or greenfield project. Majority of the times we are working on existing or brownfield projects. We should be able to identify how the requirement can be retrofit into an existing code while retaining/enhancing maintainability and not adding any technical debts.
Earlier we had observed how through Bridge design pattern we were able to structurally separate the classes so they could be extended independently. Bridge pattern is applied at the class level.
Decorator design pattern is applied to an object and not to a class. Once again this is done through composition rather than inheritance.

Let us continue with the code from the previous article in seeing how we can manage new requirements through Decorator pattern.
We’ll naturally come across a few new requirements which I am going to conjure up. Firstly, the business requires each transaction to get audited. They also require notification to be sent for certain transactions. If we look at the requirements, we need to add behaviour to the existing implementations. They need to happen when a transaction is taking place.

Any class which needs to provide a transaction needs to implement ITransaction interface. This is implemented by Personal and Corporate classes. The auditing needs to be done when there is a deposit or withdrawal. We could introduce a base class which implements auditing. This class can be inherited by those who implement ITransaction. But, we would be exhausting the only inheritance allowed on these classes since the language supports only single inheritance. Even if we go ahead with this option, it would affect all the instances of the original class. What about the other requirement? How can we apply notifications to be sent from only certain instances? If and when we decide to remove notifications, how do we efficiently do it? We cannot selectively alter the behaviour of the objects during runtime through sub-classing. Also handling both the requirements in a base class would violate the Single Responsibility Principle(SRP).

Decorator pattern helps you in applying SRP while also selectively allowing us to add behaviour to objects and in any combination.
As many examples showcase, it is not always required or necessary to have an abstract class to implement decorator. But in many cases they might be convenient to have and we’ll see why. But for now we can do without one and have just the concrete decorators. All we need is to implement the interface which we wish to extend and also have a reference of the interfaces object internally. The decorators which we implement can be stacked in any order to add behaviour and repeated too.

The new changes are highlighted in blue.

AuditTransactionDecorator implements the first requirement of audting.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class AuditTransactionDecorator : ITransaction
{
    private readonly ITransaction transaction;
    public AuditTransactionDecorator(ITransaction transaction)
    {
        this.transaction = transaction;
    }
    
    public void Deposit(decimal amount)
    {
        Console.WriteLine("Auditing amount BEFORE deposit transaction {0}", amount);
        this.transaction.Deposit(amount);
        Console.WriteLine("Auditing amount AFTER deposit transaction {0}", amount);
    }

    public decimal GetBalance()
    {
        return this.transaction.GetBalance();
    }

    public void Withdraw(decimal amount)
    {
        Console.WriteLine("Auditing amount BEFORE withdraw transaction {0}", amount);
        this.transaction.Withdraw(amount);
        Console.WriteLine("Auditing amount AFTER withdraw transaction {0}", amount);
    }
}

NotifyTransactionDecorator implements the next requirement of notifying.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

class NotifyTransactionDecorator : ITransaction
{
    private readonly ITransaction transaction;
    public NotifyTransactionDecorator(ITransaction transaction)
    {
        this.transaction = transaction;
    }
    
    public void Deposit(decimal amount)
    {
        this.transaction.Deposit(amount);
    }

    public decimal GetBalance()
    {
        return this.transaction.GetBalance();
    }

    public void Withdraw(decimal amount)
    {
        this.transaction.Withdraw(amount);
        if (amount > 100)
        {
            Console.WriteLine("NOTIFY: The amount withdrawn has exceeded $100. The amount was {0}",
             amount);
        }
    }
}

As you may notice, we are able to implement the new requirements in isolation and not having to modify the existing code.
In our AccountBase where we are creating the instance of type ITransaction, we can now decorate them with the new objects.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

abstract class AccountBase : IAccount
{
    protected ITransaction transactionImp;
    public AccountBase(string name, AccountType type)
    {
        Name = name;
        switch (type)
        {
            case AccountType.Personal:
                transactionImp = new AuditTransactionDecorator(
                                    new Personal(1000));
                break;
            case AccountType.Corporate:
                transactionImp = new NotifyTransactionDecorator(
                                    new Corporate(5000));
                break;
            default:
                throw new NotImplementedException("Unknown account type");
        }
    }

    public abstract void Deposit(decimal amount);
    public abstract void Withdraw(decimal amount);
    public abstract decimal Balance { get; }
    public string Name { get; private set; }
}

In line 10 and 14 we inject the original instance into the decorators. The decorators would now call the injected instances method along with its own. We could also stack the decorators together.

1
2
3

transactionImp = new AuditTransactionDecorator(
                    new NotifyTransactionDecorator(
                        new Corporate(5000)));

So when do we need an abstract class for decorators? Let’s take a look at our requirements again. For auditing requirement, we needed to decorate only the Deposit and Withdraw methods. For GetBalance we just had to forward the call to the internal reference of the interface’s concrete instance. For the notification, we just needed to add behaviour to the Withdraw method. Each requirement had a different set of methods being decorated. If we had to create multiple decorator classes targeting same methods, then a base class would have helped since it would provide a default implementation to methods which need to only forward the calls and allow us to implement only the targeted methods. This would also serve as a document indicating that classes derived from this base are decorators.
For example:

1
2
3
4
5
6
7
8
9
10
11
12

abstract class TransactionDecoratorBase : ITransaction
{
    internal ITransaction transaction;

    public abstract void Deposit(decimal amount);
    public abstract void Withdraw(decimal amount);

    public decimal GetBalance()
    {
        return transaction.GetBalance();
    }
}

The implementation of auditing would look like this-

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class AuditTransactionDecorator : TransactionDecoratorBase
{
    public AuditTransactionDecorator(ITransaction transaction)
    {
        this.transaction = transaction;
    }
    public override void Deposit(decimal amount)
    {
        Console.WriteLine("Auditing amount BEFORE deposit transaction {0}", amount);
        this.transaction.Deposit(amount);
        Console.WriteLine("Auditing amount AFTER deposit transaction {0}", amount);
    }
    public override void Withdraw(decimal amount)
    {
        Console.WriteLine("Auditing amount BEFORE withdraw transaction {0}", amount);
        this.transaction.Withdraw(amount);
        Console.WriteLine("Auditing amount AFTER withdraw transaction {0}", amount);
    }
}

Which takes us to the classic textbook diagram.

Only in a perfect world would we be able to realise everything at one time and place. We need to be smart about how we design our software so that we can add/change features to it during its life. You Aren’t Gonna Need It (YAGNI) and SOLID would provide us with a good start so that refactoring need not be a pain. Refactoring is all in the mindset and often teams shy away from this practise.

In this start of my series, I’ll attempt to demonstrate on how we can use design patterns to refactor your existing code. Refactoring is a great approach even when you are working on a new piece of code and not just for modifying or enhancing existing software. It keeps your design light and simple.

Let us look at an overly simplified example of an account which facilitates in conducting a basic transaction. Let us also assume that this came in as your initial requirement and the client is implemented.

IAccount is the abstraction which the clients would use.

1
2
3
4
5
6
7

interface IAccount
{
    void Deposit(decimal amount);
    void Withdraw(decimal amount);
    decimal Balance { get; }
    string Name { get; }
}

SavingAccount provides concrete implementation for IAccount.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37