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


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


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 = “Marije 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.


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.


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


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:


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:


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

This is what it does in the program:


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.



  1. Jason Down says:

    Unfortunately all the indentation is messed up in the comment.


  2. Jason Down says:

    No problem. I’m very interested in the series and will provide feedback whenever possible (I come from the C# world and I’m still fairly new to NAV). On a side note, I had a chance to see your presentations in Antwerp and thought the ideas were great. I had a chance to meet Soren and chat with him a bit about source control stuff, but I didn’t get a chance to meet you. Maybe at a future conference 🙂


  3. I’d like to see extending this to model-view-controller pattern with table as model and codeunit as controller and all together in .net 🙂


  4. Yair K. says:

    I recall an old paper by a Microsoft employee which pointed out the tension between an OO-model language to a relational model (which is how SQL Server and many other DBs for ERP programs are set up).

    The OO-model isn’t a good fit, since the relational model allows partially fetching a table**, while one can’t partially create a class (we’d have to declare a partial class for every combination of fields?). On on other hand, table as a class would allow ‘inheriting’ the table, and creating a new ‘table’ which contains only the additional members (and an ‘inherited’ table record or pointer to it). This has been done, but isn’t all that efficiently supported in SQL Server.

    The paper pointed out solutions for the problems:

    * Changing the DB to a more OO-like DB.
    * Changing the programming language to have better support for a relational model (IIRC, the term is ‘first class records’?).
    * Just scraping through, and hacking the language to work as best as possible (his preferred solution and what ends up happening most of the time).

    ** e.g. doing a ‘Group-By’ and fetching sums. What’s the ‘class’ equivalent?


Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.