The separation of platform and business logic is solved by organizing classes into the appropriate layers of the application – the user-developed layer and the metadata layer.

Between these levels, in the platform architecture, there are channels for managing the interface and managing data.

The following assembly naming convention has been adopted:
C1 – WinForms components from GrapeCity
C2 – platform system components
C3 – assemblies related to the applied solution being developed

Here, for example, the libraries developed by the user:

• C3.Accounting.Module — object modules and conduction modules
• C3.Accounting.Win — forms of objects (directories, documents, reports and processings)

Libraries created by Designer:

• C3.JustMoney.Model — applied objects (directories, documents, registers)
• C3.ModelManager — model application object access manager
• C3.ModuleManager — application object module access manager
• C3.JustMoney.Form — base classes of forms of applied objects
• C3.FormManager — application object form manager

JustMoney, Accounting, Docflow – business logic name, can be anything..

The composition of the solution libraries depends on their following functionality:

In the configuration structure, the most generalized element is the schema.

Inside each scheme there are objects of the configuration model (catalogs, documents, etc.).

An important feature is the presence of relationships between objects within the schema, at the database level using Foreign Keys. But objects in different schemes do not have this ability.

This approach allows you to build a multi-service data architecture in one configuration, distributing the development / support of schemes between different development teams.

When developing an applied solution, the developer works with model objects, for example, the “Contractor” directory or the “Invoice” document.

Accordingly, the model objects accept the same types as field values, and not identifiers and other simple types of the programming language, for example, “Invoice.Contractor = Buyer”, where “Buyer” is an instance of the “Contractor” type.

The construction of applied model types takes place in the model manager.

The framework provides guaranteed execution of predefined methods in object modules and rendering modules when writing or rendering object instances, regardless of the application context, windows application or web application.

Examples of such predefined methods are BeforeWrite, AfterWrite, Post, UnPost, and so on.

The use of such methods can be compared with triggers in databases, but with advanced features, for example, contacting a third-party service in such a method or calculating totals, and for some reason aborting a transaction, and much more that is impossible in a database trigger.