Best practices – Page 2

TempBlob Façade: a pattern proposition

Post published:October 3, 2016
Post comments:9 Comments
Reading time:8 mins read

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.

(more…)

Decoupling dependencies in C/AL

Post published:September 30, 2016
Post comments:8 Comments
Reading time:12 mins read

Directions US 2016 (yes, 2016, sorry y’all who got the 2017 link in your mailbox) was quite an event. As Directions always is, a lot of people, enthusiastic about this market we strive to thrive in, and about the product we love no matter the limitations we often face when we aim for better, more scalable architectures.

If anything, it reminded me of a long to-do list I have had around for this blog for a while, and I decided to start cleaning it up. The topic of my main session this year was loose coupling of dependencies (I called it polymorphism, because that’s what I’d ultimately like to see possible in C/AL) and I presented two patterns I came up with during my past few years.

Before I present them here on my blog, I wanted to put them in a broader context: loose coupling. So, this is what this post is all about: explaining what loose coupling is, how to achieve it in C/AL, and why you will not want to live without it ever again.

(more…)

OnAfter table event subscriber patterns and antipatterns

Post published:May 17, 2016
Post comments:18 Comments
Reading time:9 mins read

The purpose of events is to simplify business logic customization while not impeding upgradeability and general extensibility. However, there is one particular class of events that may cause troubles: OnAfter* table events. There are four of them: OnAfterInsert, OnAfterModify, OnAfterDelete, and OnAfterRename.

If you need them, you must be careful.

(more…)

A few thoughts around assembly naming and versioning for NAV

Post published:December 21, 2015
Post comments:3 Comments
Reading time:5 mins read

Are you developing .NET assemblies intended to be used from C/AL? If so, then you must have realized that keeping proper track of them and managing them on the server (or client, in case you still do that) is not a simple affair.

Assemblies in .NET are identified through their fully qualified name, and that’s how NAV tells one assembly from another, as well. Fully qualified name contains the assembly name, version, public key token, and culture information. A good practice in .NET development is that when you update assembly’s functionality, you also version that assembly up, essentially resulting in a completely new assembly, which doesn’t have the same fully qualified name as the older version did.

However, this kind of change is a breaking change. In .NET, it’s not all that breaking – you simply reference the new version and this applies to whole project. Or whole solution, depending on how you configure the MSBuild behavior.

But in NAV, it’s a completely different story. Versioning an assembly up is a very breaking change. In NAV, we cannot simply replace a reference once, and then have it apply to the whole database. Unfortunately, we have to update a reference on every single variable, and if you ever had to do it, chances are you don’t keep any happy memories about this experience.

That’s why NAV developers, when working in .NET, prefer not versioning up. And that’s wrong.

(more…)

Activity Log or Activity Lock pattern?

Post published:November 20, 2015
Post comments:5 Comments
Reading time:5 mins read

Today at NAV TechDays 2015 in Antwerp, I attended a presentation by Nikola Kukrika, Ciprian Iordache, and Gary Winter, at which Ciprian presented a new design pattern based on a new feature in NAV 2016: Activity Log.

In a nutshell, this new feature, and thus the design pattern, aim at helping trace issues and facilitate troubleshooting by leaving information in the database about what was done, by whom, if it failed, and if it did, why.

All pretty and nice, but – as Ciprian pointed out – there is a bad aspect about it: when an error happens, and everything is rolled back – the activity entry is rolled back together with everything else. Nikola later explained how this could be solved through writing into temporary tables, but this either requires redesign by Microsoft or special coding techniques by you.

However, there is a bigger caveat than this. Non-persisting data in case of errors is a problem, but the bigger problem lies elsewhere. Let me explain that bigger problem here, and then give a silver-bullet solution to solve it all.

(more…)