So, let’s continue from our last post method chaining with c#!

To recap, Jim 🧔 found a cleaner, more efficient method of building his sandwich, however he’s discovered there should be a specific order to the ingredients.

With method chaining we can’t enforce a specific order of methods called. Let’s illustrate this problem.

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

public SandwichFactory AddBread()
{
// implementation omitted for brevity
return this;
}

public SandwichFactory AddCheese()
{
// implementation omitted for brevity
return this;
}

}

We, as sandwich construction experts, want to enforce the following pattern

  • 🍞 Bread
  • 🧀 Cheese
  • 🍞 Bread

However, a consumers of our SandwichFactory class could do the following:

1
2
3
var createSandwich = new SandwichFactory()
.AddCheese()
.AddBread();

Or something worse! Let’s fix this problem.

Coming up with a nice fluent API requires a good bit of thought - Martin Fowler

Depending on the API we want to provide, complexity can rapidly escalate. For our example, we’re going to keep this small to illustrate the concepts more than application. Lets provide our solution below and go through the reasoning behind decisions made in regards to fluent 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
public sealed class SandwichFactory : ISandwichBread, ISandwichCheese
{
private SandwichFactory()
{
}

public static ISandwichBread Create => new SandwichFactory();

public ISandwichCheese AddBread()
{
throw new NotImplementedException();
}

public ISandwichBread AddCheese()
{
throw new NotImplementedException();
}
}

public interface ISandwichBread
{
ISandwichCheese AddBread();
}

public interface ISandwichCheese
{
ISandwichBread AddCheese();
}
  • The constructor needs to be private - We don’t want a direct instance of our class to be created, since this would provide access to the AddBread and AddCheese methods (which is exactly what we’re trying to avoid)!
  • Static Entry point - our entry point, in this case Create should return the interface we want to start with which is ISandwichBread and an instance of our class
  • Keep parameters low - we don’t want to use tons of parameters per method, in our example we’re using 0, but it’s something to be mindful of

Consuming the SandwichFactory API, we now can’t add cheese 🧀 before bread 🍞, since our design enforces a bread > cheese hierarchy.

1
2
3
4
SandwichFactory.Create
.AddBread()
.AddCheese()
.AddBread();

Simples! 💪

Comment and share

Scenario

Jim 🧔 is making a sandwich, he already knows which ingredients his fridge contains which he’ll be using:

  • Mayonnaise ⬜
  • Lettuce 🍃
  • Cheese 🧀
  • Ham 🥓

Jim will need to visit the fridge for each ingredient added to the sandwich. Each trip requiring a reference to the fridge, and removal of an item

Could Jim, make this sandwich creation operation better?

When we think about this scenario as code, it would be something like:

1
2
3
4
5
6
var fridge = new Fridge();

fridge.RemoveMayonnaise();
fridge.RemoveCheese();
fridge.RemoveHam();
fridge.RemoveLettuce();

Figure 1: fridge and removal of items

This pattern of calling multiple methods from an object is something very common in Object-oriented programming (OOP). Whilst perfectly valid, this suffers from some issues:

  • We’re re-referencing the object again and again, typing the word fridge and invoking a method each line
  • We’re creating a lot of noise and lines

Let’s look at how method chaining can help us here.

Continue reading

So, I encountered this for the first time today, the context being a colleague wanted to quickly FTP some files up to an Azure Web app. However no matter what directory they tried, they always got the same error:

Initially I thought they must be a permission missing from the user account, however they had got the credentials from a .PublishSettings for the web app in question

Solution

Within the XML of the publish settings file, there’s a profile entry for a [insert app name] - Readonly - FTP. This contains credentials for read only access, an easy mistake since depending on your editor, the XML file might be 1 long line. The correct FTP publish section will just have the word FTP.

Hope that saves someone some time!

Comment and share

I’ve been recently dealing with enabling multi tenancy in a full stack application, the back end being ASP.NET Core. When looking into various multi tenant libraries I found them to have one or more characteristics:

  • The apis were quite complex, and required lots of documentation parsing
  • Difficult to plug in different value resolutions
  • Require lots of boilerplate code and implementation of services

Many of these libraries are designed to use configuration files or resolution databases in order to load credentials. I don’t like this, why?

The reason is simple, most credentials don’t belong in files such as appsettings.json. Instead, these should be stored in a Key Vault which has a host of benefits such as, permission management hardware level encryption and so on. Services such as Azure Key Vault have these benefits.

Continue reading

Lazy Loading Routes

As your app becomes larger, with different modules to group feature components, a common approach is to lazy load
each module in your main routing configuration. Angular recommends this from the start, since it’s a simple yet scalable
pattern to load your projects dependencies once the route is activated.
Continue reading

Author's picture

Ash Grennan

Software engineer, mostly working with .NET, Identity, React, AWS and many other technologies.

AO.com

UK