So last week in this post I promissed you to publish the implementation patterns that help you structure your application to achieve repeatable and upgradable solutions that are easy to understand and maintain.
Not a big reader? You can watch the video of this blog post!
This is the first pattern and one of the most fundamental elements to understand before proceeding with the other patterns.
We will talk about ising classes, methods and properties in C/AL, a functional language.
Classes, Methods and Properties are elements of C#, an object oriented programming language. However there are certain elements that we can take from that language and map them to Dynamics NAV and make our daily lives easier.
This week I wrote two other posts in a series about Dynamics NAV and C# that discuss the same concept from another side. If you haven’t done so I recommend reading them first.
Dynamics NAV in C# | Part 2 | Classes (Updated)
Dynamics NAV in C# | Part 2 | Classes (Continued)
And here are the two other posts about C# and Dynamics NAV:
Dynamics NAV in C# | Part 1 | The Differences
Dynamics NAV is moving to C#, get ready to follow!
Let’s talk about the Pattern
The problem we are trying to solve with this pattern is the loose connection between tables in dynamics NAV and what you can do with it in other objects such as codeunits.
If we look at an example, we have the customer table, and a function in Codeunit 365 Format Address.
If we want to format an address in a report, as a developer I need to know that there is something like Codeunit 365, declare it as a variable and call the right function. There is nothing in Dynamics NAV that helps me find that function.
Another example, the sales header. With this I can call the post Codeunit or the Release Codeunit.
However, when I look at the sales order page, we see again that the codeunits are called as variables.
What would this look like in C#?
Let’s compare this to object oriented programming, C# and classes.
In C# the customer table would be a class and the fields would be properties that have a getter and a setter. The class has a method FormatAddress, and this calls out to a generic class.
Our Sales Header and Sales Invoice would also be classes. Probably in pure C# you would increase the object orientation with inheritance, but let’s leave this a simple example.
With a Sales Header I would be able to use the Method Post and with the Sales Invoice I could call the FormatAddress again.
Let’s do this in Dynamics NAV!
So what if we do this in Dynamics NAV.
We would create a function on the Customer Table called FormatAddress, and then on our report.
We don’t have to know the Codeunit anymore, but browsing through the Symbol Menu, the equivalent of Intellisense in the C/AL editor, I would see that a function FormatAddress exists and I just use it from my report.
The Table is the class, the Function is the Method and a Codeunit is a Class.
The same would work for the Sales Header.
This would have functions release and post. And on the page I can just call the functions.
This pattern has a number of advantages. First of all there is a clear intention of the programmer. Everything you can do with a record in the table is clearly specified on the object.
It reduces the learning curve for new developers, since by just looking at the functions in the symbol menu we can learn what we can do with the records in the table.
We can actually use the symbol menu. Using this pattern would make creating a Codeunit as a variable on pages and reports wrong. If you see a Codeunit on one of these objects, it is an indication that this pattern is not implemented.
When working on methods, developers have less chance of overlap changing the same object. This makes merging easier when the branches come together.
And it actually allows us to do versioning of business logic. This concept will be explained in another video or blog post.
There are some downsides too. If you create a Codeunit for each function, you get a lot of objects making managing the application less easy. Also having more than a hundred functions on a table does not exactly clarify the intention either.
Lastly if you call a table function from a page, the Go To Definition does not work which is highly annoying.
To avoid too many codeunits in your application, you might use the rule that if a function is less than 5 or 10 lines of code, you can write the code in the function. We’ll touch on that too when we will talk about natural language programming.