Blog

Achieving some kind of polymorphism in C/AL has always been a problem. The fact that true polymorphism with pure C/AL is outright impossible has not stopped the more stubborn of us to at least give it a try. That’s how some cool patterns emerged.

The façade pattern has been evangelized by Gary Winter so eagerly that he couldn’t find time to formally describe it. The other pattern that comes close is the variant façade pattern. It was formally described at the patterns Wiki page, but – to the best of my knowledge – was first figured out by Arend-Jan Kauffmann.

These two patterns can go a long way. No, they are not coming anywhere near true polymorphism, but will achieve some cool loose binding when you need it.

In my practice, I took a step further, and I think it’s about time I share it. Let’s see if it works for you as well as it did for me.

In my last post, I babbled at length about what loose coupling is, how both the façade and the variant façade patterns are trying to achieve it. So before you continue, if you haven’t read that post, now is a good time to do it.

Okay, now that we are on the same page, let me reintroduce the problem I put in front of you last time: shortcomings of the argument table.

First, it can only handle simple types, and if you need to pass more context that can’t reasonably be represented by a single record without paying a hefty price somewhere down the road. And then, if you want to combine it with more arguments, you loose the versatility of the CODEUNIT.RUN construct.

So, I figured out – why not use TempBlob as the argument table? It has only one useful field, called Blob (duh!) and is only intended to be used as a temporary record instance. How does that help? Well, in a ton of ways.

To start with, a Blob can hold as much information as you need. Any piece of information that runtime can handle, no matter of its type, structure, or complexity, can be represented as an array of bytes, and that’s what a blob in fact is: a binary large object, just as it says on the tin.

The only problem is, how to get anything into a blob. The answer is – serialization. That’s a term that .NET developers are far more familiar than C/AL developers, but in case you haven’t heard it yet, it’s the process of storing (serializing) an instance of an object together with its state into a format that allows storing that state outside the memory, typically for the purpose of restoring (deserializing) the object with its state later, possibly even on a different machine.

While in .NET serialization is typically only an attribute away, in C/AL we need to handle it manually. But we can handle it. We can serialize records into XML by using XMLports. Or, we can write our own serialization routines in case XMLports cannot help.

In any case – the point is – you can serialize just about anything.

And once you serialize anything, you can put it into a Blob.

Enter the TempBlob pattern:

Now, this looks a lot like the façade pattern, and in fact it is. Except that it allows you to pass far more context into the dependencies that façade, with or without variant, allows you to. Remember, a function can only have 20 parameters in C/AL, and a TempBlob can hold up to 2GB of data structured any way you want.

An example of how to pass a dictionary from one codeunit to a façade (and ultimately to the dependency) is this:

This TempBlob Management codeunit is very simple, and its purpose is to handle serialization and deserialization of stuff into TempBlob by using JSON as the serialization format (it can be anything else, but JSON is good enough).

By the way, this object is included in my Directions 2016 brownbag I posted a short while ago.

Once you have the necessary infrastructure in place, stuffing stuff into TempBlob and passing it over to a façade is easy.

For me, this pattern has solved many issues. For example, it allowed me to extend the functionality of a custom-built client wrapper for the web client, that allows me to talk to local hardware running on the client machine. When there is a new piece of hardware to talk to, I simply use a new codeunit to handle the specifics, and I pass the TempBlob into this codeunit through a common façade.

You can use it in any scenario where you’d normally use an argument table, but you find argument table insufficient, and you need more arguments than a single table can represent. In that case, you can serialize multiple table states into a single blob, and then deserialize them into multiple record instances.

Let’s compare this pattern to the two that we already know.

First, this pattern is more versatile than the argument table. It successfully addresses major argument table shortcomings, while not introducing new ones. If you want, you can take a step further, and combine argument table and TempBlob together – simply ad a BLOB field to your argument table, and use it to pass context that cannot be represented by simple types, and you have a kick-ass pattern to handle complex situations.

If I compare this to the variant façade pattern though, there is no clear winner. While TempBlob allows you the flexibility of CODEUNIT.RUN while allowing you to pass more than one distinct argument to the receiver, it is more verbose than variant façade when calling, especially when the only thing you need to do is pass a record variable. So, I’d say these two patterns simply have different use cases. And while the distinction between the use cases of argument table and variant facades is somewhat blurred, the one between the TempTable and variant facades is far more articulated.

To conclude, even though I find this pattern better than a simple argument table façade, it shares one significant drawback with it: statelessness. When you use this pattern with CODEUNIT.RUN (where it is really far superior to the variant façade) you still don’t have the possibility of retaining the state between the calls, and that’s a major drawback.

As you can see, loose coupling is really not that easy in C/AL, but is far from impossible, so you should try to use it as much as you can. Most of things we do can be loosely coupled and especially in the cloud world, and the Dynamics 365 world, loose coupling should be something we strive for in every step we make.

Microsoft Dynamics NAV 2016 brought along another paradigm which allowed loose coupling to be far more natural: eventing.

However, eventing itself, while solving a big problem, is a beast far more difficult to tame than it seams at first. In my next blog post, I’ll discuss one of the more versatile loose coupling patterns that was made possible through eventing: the “Handled” pattern. However, I find this pattern a bit messy, and will make an alternative proposal to it. And I will also address some general caveats of eventing itself, that are important to be aware of if you don’t want to fall into one of a few traps that it unintentionally sets.