Walk with me through the learning curve of a developer who is new to Business Central. We’ll assume he/she is familiar with modern web development.
I’ll give Microsoft the WOW effect. When you spin up Business Central you get more than you bargained for. Where other frameworks show you a hello world and an example of how to call a web service and display the results in a table Microsoft really gives you an incredible experience to start with.
So pages are approved. For a good reason because pages were designed as a first class three-tier citizen about a decade ago.
Next thing you want to do is to add some logic. Being a good developer you don’t want to add too much code to the UI so you start looking for the “back-end” system. Where do I write C# and how to I map this to these “pages”.
You’ve noticed that pages map to something that is called a “table”. This is weird, but ok, what’s in a name, it kinda looks like a class and there is mapping between this “table” and these “pages”.
A table looks like a class. It has properties, although they are called “fields” and there are methods which are called “procedures”.
Then you browse further in the documentation and discover a “codeunit” object. Now you are completely confused because a table and a page can be mapped somewhat to what you are familiar with, but this “codeunit” only allows for some procedures. There is no constructor, no properties.
By now you’ve probably bumped into the fact that all “objects” in Business Central need to have a number and to understand why you need to understand how things work after you’ve completed your extension.
I was probably wasting your time because there are no developers who are new to Business Central, there are only NAV dino’s trying to do what Microsoft asks them to do. Move to Extensions.
Off all the heritage that Business Central gets from NAV, object numbers are probably the most awkward one, especially if you take away C/Side where they make a lot of sense.
I’ve always tried to use Object Numbers to group my objects together that belong together. True, it’s not easy because you always have more pages than tables, but with a little help of Statical Prism and Upgrade Codeunits you can keep a clean schema.
Modern developers expect namespaces and true objects, not a file that is called an object because in the legacy system this file was stored in an Object table.
Most of you have probably given up by now but object numbers are important in combination with C/Side but they become extremely cumbersome in Business Central. Especially now that Microsoft is allowing the world to code for free in any object between 50.000 and 99.999. Who the f*ck is ever going to go through AppSource if you can sell your solutions for free!
But who is going to make sure object numbers are not already taken? How do you manage renumbering and updates?
In Dutch we have a saying, it’s neither meat or fish. Without C/Side object numbers don’t make sense and in an object-oriented world a table and a class are the same with the difference of not writing data to the database.
I promised you to explain it, didn’t I?
Many of you, or most of you, think that Microsoft wrote a new compiler for Visual Studio Code, but this is not true. It’s more of a pre-compiler or syntax checking tool that you run in the fancy modern world of VSCode where everyone can write a compiler.
When you publish your extension the real compiling begins and this is where “not much has changed”. This is not 100% true, but behind the scenes Business Central still generates C# code and these C# files get named with the object number.
If you manage to mess up the compiler, something I did last week when trying to create a Matrix Page, you’ll get a weird error message that C50000.cs does not allow to convert a NAVInt to a NAVDecimal or something along those lines.
Now, I’m not going to explain to all you kids what a Matrix Page is and where that came from, that is a bedtime story for another time.