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


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

In my last blogpost I talked about interpreting the table object in NAV as a C# class, how to use C# properties as fields and how to use C# methods as function that then map to another C# class which represents a codeunit.

The example code allowed us to create a Customer using Number Series and Format the Address.

Let’s take this one step further to really explain how this mapping is done, and how to use some of these OOP concepts back in our beloved Dynamics NAV C/AL

Sales Header

Let’s create a new class to create a Sales Header. The goal is to post the document as a Sales Invoice, we will reuse the Customer and FormatAddress classes.

2014-11-29_11-28-21

There are a couple of things I’d like to discuss in this example. It might not be the official way to do it in C#, but the idea is to be able to pass a customer class to the sales header and populate the name and the address. I also want the Order Date to be the Posting Date unless the order date is set to a different value. For the latter I probably need to add some more code like Jason shared on part I of this post.

So let’s see what happens if we create a new Sales Header like this:

2014-11-29_11-55-08In the example above we first create the customer like in the first post, then we create a new sales header and “Validate” the Customer. This populates the Name and the Address. Then we set the Posting Date, which sets the Order Date. We write the values to the console to see that it works.

Posting

Let’s repeat using a codeunit as a method and post the Sales Header to a Sales Invoice. To do this, we need the SalesPost  class that we make a method on the SalesHeader class. Like this:

2014-11-29_11-59-09

If you would have to fully design this in C#, you would probably use inheritence and try to reuse more elements, but we are trying to map C/AL to C# using the methodology we are used to in C/AL.

So we create a new C# class SalesInvoice which is a subset of the Sales Header, like table 36 and 112 in Dynamics NAV. In the SalesPost class we convert a SalesHeader into a SalesInvoice.

I’ve explored if something like TRANSFERFIELDS exist in C# and found a class on GitHub but decided not to use it for simplicity reasons.

If we use this in our example it would look something like the following:

2014-11-29_12-05-44

So we “Post” the Sales Header to a Sales Invoice and print the Customer Name to prove it works.

Let’s take it one step further…

To complete the class lesson, let’s reuse the FormatAddress on the Sales Invoice, like we would do in Dynamics NAV. In the first part of this post you’ve already seen that I had a function in my FormatAddress class that takes the Sales Invoice as a parameter.

Let’s use this, and again, we would make FormatAddress a method on the Sales Invoice class.

2014-11-29_12-09-10

You probably get the point now so let’s see what this does:

2014-11-29_12-12-39

So to briefly recap, we create a customer class and populate the address. We “Validate” that into the Sales Header and “Post” it into the Sales Invoice. Then we Format the Address.

Conclusion

The idea of this post is to explain C# from a C/AL perspective using names you recognise. A table is a class, A codeunit is a method and A field is a property.

There are probably very smart things you can do in C# to acomplish the same in a more object oriented approach. Personally I like the NAV model since it’s self explaining and simple.

This is what makes NAV rock!

Next episode: Plymorphism in Dynamics NAV. (I hope :).)

Advertisements
This entry was posted in C#. Bookmark the permalink.

3 Responses to Dynamics NAV in C# | Part 2 | Classes (Continued)

  1. Pingback: Implementation Pattern #1 | Classes, Methods and Properies | Brummel Dynamics Services B.V.

  2. Perhaps system.object.memberwiseclone is the equivalent to C/AL TRANSFERFIELDS

    Like

  3. Srđan Grandić says:

    Hi, Mark.

    I’m sure that it’s much easier for starters to simply map 1 on 1 typical NAV architecture and behavior to C# and object oriented world, but you better start at once thinking about it all in a pure OO manner. I’m sure you’ve already thought about this at some point and extent, but for others sake, imagine this, for example:

    Instead of having multiple tables/classes that represent Sales, Purchase, Service Headers and Lines, we would have one generic class called General Document (let’s call it that way). That class would have everything which is generic and mutual for all these different kinds of documents. Then we could have classes Sales, Purchase, Service, etc. Document that would inherit the class General Document and add fields/functionalities specific for each area and override some of the inherited methods. Each of these classes would have a collection member of class General Document Line which would also be inherited and overriden.

    Let’s move this to another level. Imagine a class (codeunit) called General Document Posting which would be implemented using well-known OO pattern called Template Method. You would also have posting classes (codeunits) specific to each area, but they would simply inherit the General Document Posting class and implement virtual methods inherited. Basic Posting algorithm is coded only once – in the General Document Posting class. You already have a NAV pattern for this generic posting algorithm, right? “Test Near, Test Far, Do It, Clean Up” principle.

    I’ll stop here.

    With all this said, some aspects of development and maintenance would be much, much easier.

    Liked by 1 person

Leave a Reply

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 )

Google+ photo

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

Connecting to %s