Whoa! This has been quite an event, the Directions EMEA 2016 in Prague. There has never been this many people (1.700+) and it was quite a pleasure connecting again with old friends, and meeting new friends. Also, it has been quite a pleasure listening to many good sessions, and an even bigger pleasure delivering four of them.
And this is why I am blogging now – to follow up on my promise during my Polymorphic Event Patterns for C/AL. I promised you that I’d post my pattern proposal online, and here I am doing it.
Let’s get started.
Continue reading Module Binder Pattern proposal
I’ve delved deep into design patterns story with my last two blog posts, but I am far from over. The patterns I discussed are the ones we could use up until NAV 2015 (we can still use them, of course!) but some more robust loose coupling (excuse the near-oxymoron) can be achieved with what NAV 2016 brought along: events.
It’s the “Handled” pattern. This pattern comes from Thomas Hejlsberg, a chief architect and CTO of Microsoft Dynamics NAV, and was first described by Mark Brummel on his blog. It’s a powerful loose-coupling pattern that successfully addresses the shortcomings of all design patterns I discussed earlier. I would prefer calling this pattern Event Façade rather than “Handled”, but it’s not my baby to christen.
Let’s take a look.
Continue reading Gentlemen’s agreement pattern, or handling the “Handled” pattern
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.
Continue reading TempBlob Façade: a pattern proposition
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.
Continue reading OnAfter table event subscriber patterns and antipatterns
When you spend more time in C# than C/AL, and you still tell yourself and the world around you that you are developing for NAV, then this post is for you.
I already wrote a three-article series about “DLL hell” and how to resolve it, and in my last post in the series (http://vjeko.com/sorting-out-the-dll-hell-part-3-the-code) I delivered some code that help you take control of your .NET assemblies.
This time, I am delivering an updated solution, one that solves all the problems others, and myself, have encountered in the meantime.
So, fasten the seatbelt, and let’s embark on another .NET interoperability black belt ride.
Continue reading Dynamically loading assemblies at runtime