区分基础应用和系统应用

AL 开发人员可以通过多种方式扩展 Business Central 的功能。他们可以扩展表、枚举、应用程序区域、页面、报表、代码流和安全模型。对于系统应用程序模块，他们还可以直接为其开源项目中的基础应用程序做出贡献。

Business Central 应用程序由多个层组成：

系统应用程序概述

系统应用程序中包含的模块可与 Dynamics 365 Business Central 平台和在线生态系统进行交互，以支持基础应用程序中的业务逻辑。如果您在开发 Dynamics 365 Business Central 的扩展或附加产品，可能需要使用这些模块中的一个或多个对象。

有关系统应用程序中各模块的概述，请参阅系统应用程序中的模块概述。

在系统应用程序部分，您可以找到 Business Central 中构成系统应用层的所有对象的概览，还包括按对象类型排序的已弃用对象。在基础应用程序部分，您可以找到 Business Central 中构成基础应用层的所有对象的概览。这其中还包括已弃用对象的部分，它们按对象类型排序。

尽管各模块的内部体系结构可以（而且很可能会）各不相同，但一些规则可以确保应用程序各模块体系结构的一致性和可靠性。为了减少耦合并提高一致性，每个模块都是一个独立的实体，具有可公开访问的对外部分，而内部实现则不公开，如下图所示。

各模块是独立项目，有自己的 app.json 文件。

模块可以属于特定包或功能层。当模块添加到某个层中包的文件夹结构时，它就成为该层的一部分。一个模块可以属于多个包，因为模块本身就是一个包，并且可以捆绑到更大的功能分层包中。

一个模块只能依赖于位于同一功能层或更低层的模块。例如，核心应用程序中的一个模块只能依赖于核心应用程序或系统应用程序中的模块，而绝不会依赖于扩展。

每个模块最初都必须针对最严格的环境，即云环境。如果需要进行不安全的操作，那么应该生成一个系统应用程序模块，在其中，不安全的操作被安全的 API 包装起来。为此，需要将目标设置为 OnPrem。系统应用程序之上的层中的模块，必须在 app.json 文件中将目标设置为云。

只有该模块公共 API 中所需的对外部分 codeunit、页面和表是可访问的。必须通过将访问修饰符设置为 Internal 来标记内部实现细节。例如，可以在模块内部访问实体，但不能从模块外部调用实体。

每个模块必须有满足以下规则的对外部分：

访问权限必须为公共。应该明确设置访问权限，以强调这是一个对外部分或类似 API 的 codeunit，公开了模块中的核心功能。
所有集成和业务事件发布程序都必须作为内部功能出现在对外部分中。这样可以防止它们在模块外部被调用。
事件发布程序应标记为 Internal。必须记录例外情况。
所有外部方法都处于对外部分中。
对外部分不能包含逻辑或本地功能。
因为对外部分是其他模块引用的 codeunit，所以它应该有一个简短、有意义的名称。例如，内部实现 codeunit 可以带有后缀 Impl，因为它们不会在模块外部被引用。

实现 codeunit 包含业务逻辑。页面和表可以包含代码，但只应在绝对必要时才这样做。

每个模块的内部实现都必须考虑可扩展性。如果模块不应扩展，则表、页面和枚举的 Extensibility 属性必须设置为 False 以防止扩展这些对象。

您可以在以下文档中了解如何开发模块：

如果您想向 Business Central 开源系统应用程序贡献代码，需要先确定属于以下哪种贡献类型：

要了解有关系统应用程序、其模块体系结构以及如何修改或创建新模块的更多信息，请转至模块体系结构。