Tag Archives: C#

Implementation Pattern #1 | Classes, Methods and Properies

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.

2014-11-29_20-25-52

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.

2014-11-29_20-29-07

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.

2014-11-29_20-29-52

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.

2014-11-29_20-31-08

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.

2014-11-29_20-32-25

We would create a function on the Customer Table called FormatAddress, and then on our report.

2014-11-29_20-33-17

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.

2014-11-29_20-33-54

The Table is the class, the Function is the Method and a Codeunit is a Class.

The same would work for the Sales Header.

2014-11-29_20-34-40

This would have functions release and post. And on the page I can just call the functions.

Advantages

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.

2014-11-29_20-36-10

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.

Downsides

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.

2014-11-29_20-36-49

Lastly if you call a table function from a page, the Go To Definition does not work which is highly annoying.

2014-11-29_20-36-59

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.

Dynamics NAV in C# | Part 2 | Classes (Updated)

Disclaimer: If you are a skilled C# developer, I apologize for any mistakes I made, they we unintentional. 🙂

UPDATE (29/nov/2014): Based on the feedback from Jason Down I changed the C# code to get the number from the number series class.

Ok, there we go. No more conferences so time to do some actual blogging.

This is part 2 of my NAV in C# series. If you have not done so, please read part 1.

In this episode we will talk about classes.

In C# a class is very powerfull. It’s a datatype that you can form yourself giving it properties and methods. And since C# is object oriented, you can inherit from classes etc.

But let’s not get into these details. The blog series is intended to explain C# from a Dynamics NAV perspective.

So how do we map a class to Dynamics NAV.

Actually you could see a table or a codeunit as a class.

A Table is a Class

Let’s start with that. Let’s have a look at the customer table in NAV. It has a bunch of fields

2014-11-27_21-38-07

So how would something like that look like in C#:

2014-11-27_21-41-27

Each field is a property. You can see that it is a property because it has the { get; set; } syntax

If you would like to code against it you would declare a new customer like this

Customer Cust = new Customer();

Cust.Name = “Mark Brummel”;

Cust.Address = “Somewhere”;

This would create a new instance of the class and populate the name

Number Series

But we have number series in NAV.  So let’s make that

A Codeunit as a class

Let’s make a class that can return number series.

2014-11-27_21-46-58

This is a very simple class with a method that returns a number. It should be smarter but I hope it explains the idea

Return the number in the customer

So what if we want to assign this number to the customer? In C/AL we would have triggers. In this example we would use the getter, and store the value in a variable. This latter would off-course be done in the SQL Table in NAV itsself.

2014-11-29_11-10-04.

In the property we return the value of the number series. See how easy that is?

Now if we create a sample application that would create a customer we would have this

2014-11-27_21-51-24

So we have a new customer with a number, that we do not declare in the class, it is automatically added, like in Dynamics NAV

What about address formatting

So we print the address, but what if I want to do that like in NAV? Then we need a new codeunit class, and we would add a method to the class, like this:

2014-11-27_21-54-02

This class takes a customer as a parameter and calls into a generic function to move the address to an array. It also has a function for the Sales Invoice, a class we will use in the next blog post.

A Codeunit is a Method

In C# we would add the adressformating as a method that we can do with a class. This way we don’t have to call the addressformatting class in our programm.

Like this:

2014-11-27_21-56-00

And the keyword this stands for what we would cal Rec in Dynamics NAV.

This is what it does in the program:

2014-11-27_21-58-07

A Table is a Class, A Codeunit is a Method (and a class)

So a table definition (not the actual SQL table) would be a class and a codeunit too, and added to the table class.

This actually would work nice in NAV too, if we would declare things like FormatAddress on the table, we would never have to use Codeunits as a variable anymore.

Next time…

I will explain how to create a sales order in C# and how to post it to a sales invoice.

Hang on, stay tuned.