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.
Unfortunately all the indentation is messed up in the comment.
LikeLike
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 🙂
LikeLike
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 🙂
LikeLike
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?
LikeLike