Idiom v. Idiom – void static abstract

Comparison

I’ve mentioned before that idiom gets in the way of translating between .NET and C/AL. These are a few of the terms that may be confusing (or may not exist at all) between the two environments.

Enjoy the list and don’t think it’s complete.

Types vs. Classes

C/AL	.NET
Types	Classes
The types in C/AL are: Table Page Report Codeunit Query XMLport and MenuSuite	Object-oriented complex type. A class is a definition a specific definition. We’re told that everything in .NET is an object. This is untrue. Value types — ints, bool, char, etc. — store data directly. All other types are reference types and derive from System.Object. This makes them objects.

.NET File Types

C/AL	.NET
Nothing comparable	File types
There’s nothing like this in C/AL	In Visual Studio and .NET, many projects depend on a host of files that are not code, but used by the compiler or by the run-time. (There’s no run-time in C/AL, either. At least not one we can control.) Examples of file types are views, html files, config files, javascript files, css, and others. Some of these, like the *.js files, contain code… just not .NET. But the .NET environment allows the developer to consume these additional file types as part of a project.

C/AL

.NET

Nothing comparable

File types

There’s nothing like this in C/AL

In Visual Studio and .NET, many projects depend on a host of files that are not code, but used by the compiler or by the run-time.
(There’s no run-time in C/AL, either. At least not one we can control.)
Examples of file types are views, html files, config files, javascript files, css, and others. Some of these, like the *.js files, contain code… just not .NET. But the .NET environment allows the developer to consume these additional file types as part of a project.

Properties

C/AL	.NET
Properties	Properties
Settings that cross over both visual presentation, data storage, and even initial values can be changed in the C/AL properties dialog. Different types of fields have different properties. Different NAV object types have different properties, too. An image of the Amount (LCY) field is shown below.	In .NET (C#) properties are a shorthand provided to read, write, or even calculate results for a class member. Sometimes they’re called “getters and setters.” They are always members of a class.
	public string Greeting { get {return greeting;} set {greeting = value;}) }

Example

Unfairly as we may find it, comparing C/AL against the S.O.L.I.D. practices and patterns, many of these NAV properties commit a huge domain violation.

This reveals another design difference between NAV and .NET that we cannot ignore: NAV design and development integrates all objects (NAV Types) simultaneously! Tables, especially, violate both the Single Responsibility Principle and the Interface Segregation Principle.

Properties for a table.. for a field… reveal a caption, an autoformat, and even an access property; ranging from presentation layer to input rules to security and permissions; this set of properties violates a lot of domain boundaries all at the same time.

We come to realize that NAV cannot exist without all types working together at all times. As hard as we may try, clean code is far beyond us in NAV.

Web Services

C/AL	.NET
NAV uses a saas trick to generate web services from some of the object types in NAV. Pages and Codeunits can be marked as web services and the NAV service layer will expose these types as HTTP SOAP service interfaces. Security and authentication rely on the Active Directory backbone and the setup information for users in NAV. (For instance, if an A/D user cannot see payment data, then the SOAP service will interpret the query to limit those data. This can be a boon for lazy programmers.) NAV web services must run from a NAV service layer running in, at best, a DMZ, at worst, the same server on which all the other NAV services reside. Additionally, NAV web services connect directly to the NAV database and have the authority of the A/D user.	.NET developers interpret this word much differently. A web service is a combination of protocols (HTTP, TCP, MSMQ), encodings (SOAP, REST), over multiple transports (binary, text, etc.). Security and authentication of the multiple web services can leverage active directory, two-factor authentication, single sign-on, or any other security protocols. These, and other factors, make developing .NET web services a complex design challenge. But the .NET developer also has total control over the service.

C/AL

.NET

NAV uses a saas trick to generate web services from some of the object types in NAV. Pages and Codeunits can be marked as web services and the NAV service layer will expose these types as HTTP SOAP service interfaces.
Security and authentication rely on the Active Directory backbone and the setup information for users in NAV. (For instance, if an A/D user cannot see payment data, then the SOAP service will interpret the query to limit those data. This can be a boon for lazy programmers.)
NAV web services must run from a NAV service layer running in, at best, a DMZ, at worst, the same server on which all the other NAV services reside.
Additionally, NAV web services connect directly to the NAV database and have the authority of the A/D user.

.NET developers interpret this word much differently. A web service is a combination of protocols (HTTP, TCP, MSMQ), encodings (SOAP, REST), over multiple transports (binary, text, etc.).
Security and authentication of the multiple web services can leverage active directory, two-factor authentication, single sign-on, or any other security protocols.
These, and other factors, make developing .NET web services a complex design challenge. But the .NET developer also has total control over the service.

Identifiers

C/AL

.NET

Numerics

Identifiers

It’s an odd thing. The real identifier in all of NAV is a number. NAV Objects exist in a specific number range. The full range of numbers in NAV goes from 1 to 999,999,999.
It’s broken up into these sub-ranges.

1 – 49999	NAV Native objects and fields.
50000 – 99999	Custom Range available to any solution center. Not protected.
1000000 – 59999999	Assigned to specific ISVs for protected extensions and add-ins.
70000000 – 79999999	New range set aside just for B365 Multi-tenant on Azure.
99000000 – 99999999	NAV Native Production range
2000000000 – 2999999999	NAV system and virtual range.

In .NET, everything is separated by a fully-qualified name.
A fully-qualified name inclues the namespace, the object instance name, and the identifier. There are no numeric ranges. (And no licensing issues for developers.)