Layers used to be the defining technology of the Axapta/AX framework. They were something that could be used to detect a true AX developer. "Explain to my what layers are?" you could ask in an interview to detect a faker from a real X++ expert. They were always the first concept I would teach in a development class. Without understanding them, you could instantly make a mess from your first line of X++ code. "Someone coded in the USR layer!" you could hear people exclaim, with an incredulous tone in their voice.
This is now a thing of the past. Layers are not what they used to be. In fact, they really hold no meaning in AX7. As I've been digesting all the new AX7 concepts, I've been trying to understand what things have directly replaced, or in some cases, what they have made redundant altogether. I've come up with a few ideas, but I'm really not 100% sure yet. Here's my current thinking about layers specifically:
OLD: Layers NEW: Packages
There are a finite number of layers you can use, from SYS through to USP. This always caused a problem when trying to define what exactly should live in each layer (especially with multiple ISV solutions). Models helped this problem immensely when they were introduced in AX2012, allow us to chop up layers into smaller chunks, and define metadata against them.
Packages seem to be the closest sibling to layers in AX7. But unlike layers, you can have as many packages as you like. Microsoft ships a long list of their own packages in standard AX7 product, the most important ones being ApplicationFoundation, ApplicationPlatform, and ApplicationSuite. The shipped AX code is divided across their packages. For example, code related to the platform itself is in the ApplicationPlatform package, code related to Tax is in the Tax package. So whereas Microsoft code used to ship in a single SYS layer, it now ships in multiple packages. When deployed, packages are synonymous with DLL files, but that’s not really something we need to be acutely aware of.
OLD: Models NEW: Models (and Packages)
Models continue to exist in AX7. They have a very close relationship to packages, and you could even say that the role of a model, as it was in AX2012, is now shared by packages and models. A package is group of models. When you create a new model, you need to choose which package it will live in. I will go into more detail about this, when I eventually discuss overlayering versus extensions, and how models and packages affect these decisions - but that’s for another blog. An important thing to remember when designing packages and models, is that code in the same package must be deployed at the same time – it is our new Smallest Deployable Unit (a title held by models in AX2012). So artifacts that comprise a single solution (like a modification covered by a single specification document), should exist in the same package. They don’t necessarily have to live in a single model within the package – the model structure is up to you. This feels like a concept that people will have different opinions about, so please don’t destroy me in the comments if you disagree.
While discussing packages, I should mention that Microsoft seem to have an affection for this word. There are many concepts with the word "package" in them in AX7, and they are all different.
- A package, as I have discussed here, is a collection of models, that deploys into a DLL file.
- A deployable package is a group of 1 or more packages, that can be published into an AX instance. This is how code is now promoted into your Azure-hosted environments. This concept only exists in LCS, where you can import a
deployable package into your Asset Library.
- A data package is a collection of files containing data to import into an AX instance. It has nothing to do with code.
For those that just can't let go of layers so quickly, there is still an option to choose a layer for your AX7 model, but it's really just there to make you feel nostalgic:
I hope this blog helped you understand packages, and how they have (sort-of) replaced layers. If you have a different opinion, or something extra to add, please send me a comment below.