Directions EMEA has just ended .. and how great that was! Let’s see if I will come to writing up a “final thoughts” .. . That’s not for today.
After some “Extension-Extension-writing” recently, I wanted to put out my own thoughts. My first version was a very long blogpost. But since I just bothered you with an insanely long post (for which I apologize ;-)), I decided to do this in three posts :-):
In this post, I’ll have a look at what we had, have and might expect.
Microsoft Dynamics NAV 2016 gave us Extensions. From day zero (when still in beta), I have been diving into it – creating a “kick-ass” (not really..) Rental Extension for demo-purposes together with Gary. And when you looked at it, you had the impression that everything was possible!
Well – not really. It was quite a pain to develop this Extension. Like:
Also, to be able to create an extension, you needed to manage the fact you have original and modified, compare them, create deltas and so on. Although – if you put a bit of time into PowerShell, this didn’t have to be painful at all.. .
That was the situation in the past. In my opinion, this was a prototype.
In NAV2017, we see an immense improvement in the capabilities, which I blogged about here. About all is possible now! Sure, we’re still working with Extensions as being mainly a collection of deltas (and some other files that include other things like web services, permission sets, add-ins,… ). But, thanks to the fact Microsoft already released a version of Extensions in NAV2016 (the prototype), we all have been diving into it, right? So the PowerShell scripts are still there! I had to do limited changes on my scripts to facilitate NAV2017 Extensions. And now, it takes me literally 5 clicks to start developing a new Extension, or to set up a DEV environment out of my GitHub to continue developing on an existing one. Like I have now put WaldoNAVPad into an Extension. (If you want to see this example, it’s all on GitHub. Powershell, NAV code, AddIn, everything .. feel free to have a look).
To be honest, I can hardly see any limitations to develop Extensions. Sure, sometimes you have to rethink your code-structure a bit … but that’s because we’re so used to change objects rather than extend them.
I mean .. think of it .. there are design patterns that facilitate upgrade .. which many of us embraced as being good practice! These patterns basically minimize the footprint in code. We all know that these patterns do not facilitate readability. But we accept them, because we want easier upgrades. Right?
Well, guess what. Extensions facilitate upgrades as well .. even better than any existing design pattern .. so let’s implement design patterns that facilitate Extensions .. . This is not so different.
That does not mean that I think this current version is ready for on premise customizations or verticals. Simply by the fact that at this time, there just aren’t enough events. And of course, Microsoft is on it: codeunits like 80, 90, 229, … are completely restructured .. and we will be able to see more and more events in the near future. Probably already in CU’s.
There is only one conclusion: look at the giant leap Microsoft has taken towards an Extension-only development model (if I may call it like that..).
If you’re still denying Extensions .. you’re just plain wrong.
If you’re still avoid diving into it .. you’re just plain wrong.
And that’s only my opinion.
Future – The ultimate dream
As said, I strongly believe that Microsoft is working towards an “Extensions Only” model. All customizations, all customizations on top of customizations – it’s going to be all Extensions. And that’s a good thing.
Just think about this:
The entire default database is a reference model. In your development environment you reference to this model (like you can create references in Visual Studio to any kind of libraries). By referencing, you get your objects, functions .. whatever you can program against, like codeunit 80, pages, … whatever. AND you get your events, to be able to use to hook into code. So in a way, I would be only creating new objects, by using references to existing classes. I would create new “classes” (let’s call them Extension Objects) to extend existing objects. This is exactly what I believe Microsoft is working on. Arend-Jan Kauffman already talked about this in his blog. Please read – it makes all the sense!
.Net people would say: uhm, ok, duh, that’s how we do stuff, indeed. But for NAV developers, this is a big change.
Because we are used to change any existing piece of code.
Some people hide behind the fact that this is an “Open Source” model. In my opinion, this absolutely has nothing to do with Open Source. “Open Source” is a community model where the community works on one code base. We don’t do that. We can read a certain codebase, created by Microsoft, and we modify it for every customer. It’s the complete opposite of open source – and can’t be compared with any orthodox software development environment. Call it a “Copy/Paste/Modify”-model. We’re not extending, we’re changing .. and in many cases, we are “breaking”. I call it “job protection”.
So why not work towards a model that is AS flexible AND we solve the upgrade-issue as well? Let’s not copy-paste-modify .. but just “reference-and-extend”.
Will it come with new pain points? Maybe so, but it will also solve a lot of other ones.
I truly believe that Extensions is going to be the solution for many pain points we have today. May be they are not already .. . But in the future they will! For On Premise, for customizations, for your private and public cloud. And guess what .. for Dynamics365 they already are!