Model split
This article explains the split of the stack into three main models - the Application Platform, the Application Foundation, and the Application Suite.
Overview
Developing modular code is the driving force behind the model split. Splitting the stack into multiple models provides many benefits, including faster compile time and a greater distinction between partner's IP in production. There are three main models: the Application Platform, the Application Foundation, and the Application Suite.
The Application Platform is the lowest model and contains the lowest level elements that interface with the kernel. The Application Object Server (AOS) can be started with only the Application Platform. The Application Foundation sits atop the Application Platform and contains framework functionalities that are shared by all applications. Finally, the Application Suite sits atop the Application Foundation and contains application specific elements. The Model Breakdown table in the appendix provides examples of components in each of these models. Each model is compiled into its own assembly with dependencies on lower layer model assemblies. The Application Platform does not depend on any other models. This implies a direct mapping of the model to an assembly.
Developing in the modular stack allows changes to be made in the Application Suite and compiled without touching the rest of the stack. Only models with new changes need to be compiled, greatly reducing compile time. More information can be found in the "Model Breakdown" section at the end of this article.
Customizing models
There are two methods for customizing: overlayering and extensions. Overlayering allows for changes to be made at multiple layers that alter, or overlay, elements in models at lower levels. Extensions allow for new elements to be added or code to be attached to element events or plug-in points. The type of customization used impacts how a model will be compiled and ultimately packaged. One or more models are compiled into an assembly. An assembly, its non-code metadata, and its compiled artifacts, form a package. A package is an independent deployable unit. A model that contains only extension customizations can be compiled into its own assembly and be deployed in its own package. A model that contains any overlayering must be compiled into the assembly based on the overlayed model.
Using extensions has several advantages, including:
- For application lifecycle management purposes, you need to manage only your extension artifacts.
- Building a customization does not require you to recompile the entire application.
- In the cloud, Microsoft can install, patch, upgrade, and change internal APIs without affecting your customizations.
- You can service your solutions independently without concerns about other customizations.
There are currently support code extensions, table extensions, form extensions, menu extensions, and enum extensions. The Extensions section in Customize through extension and overlayering and Customize model elements through extension provide a more detailed explanation on how to use extensions. Extensions should be used on supported elements wherever possible and are best applied when no change to existing Microsoft code is needed. A change to mask a method’s functionality requires overlayering to change the code itself. Overlayering should be in areas not covered by extensions and when the customization alters the base functionality. The illustration below summarizes differences between the two customization strategies.
Model breakdown
| Model | Concept |
| Application Platform | The Application Platform interfaces to kernel functionalities that are application logic agnostic. The AOS can be started with just this model.
|
| Application Foundation |
|
| Application Suite |
|