How do we in 1C: Enterprise work with data models (or “Why do we not work with tables?”)
In this article we want to talk about what model of work with data is selected in the 1C: Enterprise platform and why.
For business applications, working with data is a very important architectural issue. One way or another, the entire work of the application is built around data. Moreover, if in some classes of software systems the data are of an auxiliary nature, in business applications the data is the main content of the tasks to be solved.
Here (in this article) we are not talking about the technical aspect of storing and manipulating data, but about describing data as a way to design an application. Why is data so important for business applications?
Because they describe the subject area itself. What entities are in business, how are they related. The data very well describe the task itself. After all, when designing applications, we are not interested in absolutely all the data, but are interested in those data (and their interrelationships) that in one way or another affect the problem being solved (including some reserve of system development in potentially interesting directions). For example, if we automate the process of personnel development, then we will be interested in education, work history by employees. But we will not reflect information on the size of clothes and shoes. But, if, for example, we want to automate the accounting of workwear, then it becomes interesting. Although, an inquisitive designer can put the question here. Where the development of staff, there is motivation. And where is the motivation, there and, perhaps, the manufacture of clothing with brand logo. Here it can be seen that the amount of data in nature is infinite, and the art of data modeling largely determines the art of designing applications.
')
Of course, a very important place in business applications and occupy processes. Although there is a strong desire (both for us and developers of other platforms for developing business applications) to place greater weight on application design on processes, but the data still remains the most significant aspect of the subject area. And it is on the reflection of the data that the main application model is built.
We make only a small reservation. Data here refers to data accompanying processes. That is, it turns out that the processes are also indirectly expressed through the data model.
In the 1C: Enterprise platform, there are mechanisms for reflecting processes, but this is the topic of a separate article.
There are several traditional paradigms for working with data.
First of all - there is a classic relational model. It describes the data as relational tables (usually stored in relational DBMS). This paradigm, though not at all new, is quite relevant.
There is an object paradigm. It describes the data as objects of a programming language and is somehow stored in a database. This can be a relational or object database. In the first case, the simulation capabilities are determined by the DBMS , in the second case, the ORM used.
There are also techniques and approaches that are used less frequently (when creating business applications). For example, an approach based on semistructured data.
Now, in fact, about the approach that we have chosen for the 1C: Enterprise platform. For him there is no officially accepted name. Let's call it “the type model of applied objects”. The essence of the approach is that the platform offers the developer a certain set of types of application objects. Each type is intended to be reflected in the application model of a certain category of domain entities. The application developer, when reflecting the domain of the problem being solved in the application model, should select the appropriate types of objects and use them to describe the data model. In fact, while he describes not only the data model, but, in many respects, the model of the application itself. But more on that later.
What is the type of application object?
This is some kind of template embedded in the platform (it can also be considered an abstract class), defining many different aspects of working with the essence of the domain.
Types of application objects appear during development (in design-time) and during system operation (in run-time). In design-time, this is a meta-model for describing objects in metadata and classes for manipulating data in a program model. In run-time these are various aspects of the system behavior when working with objects of this type. For example, the behavior of the lock mechanism.
In 1C: Enterprise there are several types of application objects.
For example, take three types:
Directories are intended to reflect in the system some conditionally permanent information (lists of employees, goods, clients ...).
Documents reflect some of the events of the subject area (sale, recruitment, transfer of money to the bank). Sometimes they are called by the name of printed forms (“payment order”, “order for admission to work”, ...). But this is just for convenience of understanding. In fact, this is exactly the type of event, not the printed form.
Accumulation registers are intended to be reflected in the application of some accounting system. For example, accounting storage of cash or goods in warehouses.
Let's see what all the same is included in the "set" of opportunities provided by the types of application objects
First of all, of course, the type of application object describes the data model and provides data mapping to the relational storage model. But this is only a small part of what it defines.
For example, for reference:
For a document, it looks like, but there is a standard attribute, Date, which reflects the position of the event relative to other events on the time axis, as well as the “Done” feature, which determines whether the document is reflected in the accounting system or is a draft.
For the register of accumulation of the field are divided into dimensions, resources and details. Dimensions describe the coordinate system of the accounting model (for example, product, warehouse), resources - indicators (for example, quantity, sum), details - just additional fields (which do not affect the accounting model, but commenting on the movement records).
Why do we operate with types of application objects, and do not operate, for example, with just tables (or just entities)?
This is a very important point. Tables have many advantages. They are closer to the simplest modeling in the relational model; they do not limit the developer to the framework of the types inherent. But the tables and do not give those opportunities that gives us the chosen approach.
The essence of the approach we have chosen is (to put it in simple terms) that in our approach the system (platform) itself “knows a lot of things” about the objects described and “knows a lot of things with them”. Based on this knowledge and skills, the system automatically provides more than a dozen different mechanisms that work directly or indirectly with these objects. That is, it turns out that the application developer chooses the type of object and describes a specific object, and the platform, knowing the type and description of a specific object, provides many different useful functions and mechanisms. This is achieved due to the fact that the semantics of objects of a given type are defined at the level of an object type (the object's purpose is “large”), and the metadata model allows specifying the semantics of a specific object due to various properties and specialized models describing various aspects of life activity.
We list only some of them:
The diagram shows not all the platform mechanisms that operate on the basis of application objects, but only some.
In a sense, the types of application objects intersect with the aspect-oriented approach. Since all of the listed opportunities are some predefined aspects that reflect the types of application objects. It can be said that the types of application objects are not just templates, but parameterized templates. Parameterization is carried out by a set of metadata properties. By selecting the property value, the developer parametrizes the template of the selected type of application object and specifies the behavior of the object in a particular aspect. For example, he can select the type of document numbering (within a year, quarter, month ...) and the system will automatically ensure the assignment and control of numbers with a specified frequency.
Types of applied objects provide knowledge of the semantics not only of the entities themselves, but also of the semantics of their interrelationships. For example, there is a standard link between documents and registers, reflecting how events are reflected in the accounting model in the subject area. Having identified such a link, the developer immediately obtains the finished functionality for the joint lifetime of the document and the associated registry entries.
Separately, it is worth mentioning important subject-oriented aspects.
For example, for reference books it is possible to enable hierarchy support with one checkbox. At the same time, the system will provide support for hierarchical directories in everything: in the user interface, in reports, in the object model.
Setting one directory property “Hierarchical Reference” immediately supports hierarchy in the user interface, in reports, in the object model.
For documents, there are opportunities such as journals, combining several types of documents, continuous numbering by periods, etc.
For accumulation registers, the most important possibility is the automatic storage of calculated totals and ready-made virtual tables for access to the results in various sections and taking into account the periodicity.
That is, in essence, an essential part of the universal (typical) mechanisms of the application business logic, characteristic for the relevant data category of the domain, is incorporated into the types of application objects.
It turns out that the developer assembles the application from the objects of the selected types, as from the details of the designer. Moreover, if there are designers with “abstract” parts, then in our designer parts are already with “purpose” - wheels, windows, doors ...
Based on the “Directory” type, the developer builds reference books of products, employees, currencies, clients; based on the type of "Document" - documents "Purchase Order", "Account", "Sales Order", etc.
Still it is necessary to say about the methodological value of this approach. All developers operate with a certain set of concepts that helps them to better understand the essence of applications, simplifies communication. Having opened an unfamiliar 1C: Enterprise project, the developer immediately sees familiar concepts and can quickly figure out what role this or that object plays in the system. For example, to understand the essence of the application, it is worth looking at the list of registers - usually it reflects the main purpose of the application. If you open the structure of tables or, moreover, the structure of classes of an unfamiliar application written on tools that operate on tables and classes, then there will be significantly less understanding.
But, more importantly, this approach brings the language of developers and business representatives (or analysts) closer together. About the need for such a language is well said in the book “Subject-oriented design (DDD). Structuring Complex Software Systems ”by Eric Evans. The types of application objects quickly become understandable to non-programmers, and this allows analysts, customers and developers to discuss the main project functionality in the same language. Often you can meet representatives of business or analysts who do not own programming, but can set the task in terms of the types of 1C: Enterprise application objects.
What else is interesting. This approach ensures the continuous development of the system. We add new mechanisms to the platform, and they immediately start working for already existing objects (without the efforts of an application developer or with minimal effort). For example, we recently developed a mechanism for storing data history (versioning) . Since the system knows in general about the semantics of the data, the developer simply tick the box that he wants to store the data history of a specific object, and the platform provides everything that is needed, from storing the history to visualization - displaying the history of changes to the user as various reports. When we previously developed the standard REST interface mechanism (based on the OData standard), a ready-made REST interface immediately appeared in all applications. Developers did not have to modify anything for this.
Why don't we also make “just tables” (in addition to the ready-made types of application objects)? This is a difficult question. We ourselves ask it periodically.
On the one hand, this seems tempting. So we would close all disputable cases where the subject area does not ideally fit into the set of types of application objects we prepared. It was possible to say to the developers - “well, here is just a table for you - and do everything in it as you wish.” But on the other hand, this will lead to the fact that all our standard mechanisms will be “at a loss” - how do they deal with these tables? After all, they will not know the semantics of this data and will not be able to figure out how to work with them correctly. Well, that is, you can work with them "somehow." Strictly speaking, we have such experience in terms of external sources. For external sources, we describe exactly the tables (without specifying the subject orientation). And the system works with them in some universal way - at the same time, some of the functionality is not supported.
For the time being, we still try to refrain from introducing “just tables” in order to ensure the purity of the model and the ability to add new functionality based on the knowledge of the semantics of all data. If some opportunities are not enough, then at first we will still consider how to develop the types of applied objects. But, of course, this is a debatable question, and we will continue to think about it.
Thus, the possibilities that the 1C: Enterprise platform provides in its finished form, and the increase in the level of abstraction that is appreciated by application developers, is largely based on a set of types of application objects. This is one of the most significant differences between 1C: Enterprise and other development tools and one of the main tools that ensures rapid and unified development.
For business applications, working with data is a very important architectural issue. One way or another, the entire work of the application is built around data. Moreover, if in some classes of software systems the data are of an auxiliary nature, in business applications the data is the main content of the tasks to be solved.
Here (in this article) we are not talking about the technical aspect of storing and manipulating data, but about describing data as a way to design an application. Why is data so important for business applications?
Because they describe the subject area itself. What entities are in business, how are they related. The data very well describe the task itself. After all, when designing applications, we are not interested in absolutely all the data, but are interested in those data (and their interrelationships) that in one way or another affect the problem being solved (including some reserve of system development in potentially interesting directions). For example, if we automate the process of personnel development, then we will be interested in education, work history by employees. But we will not reflect information on the size of clothes and shoes. But, if, for example, we want to automate the accounting of workwear, then it becomes interesting. Although, an inquisitive designer can put the question here. Where the development of staff, there is motivation. And where is the motivation, there and, perhaps, the manufacture of clothing with brand logo. Here it can be seen that the amount of data in nature is infinite, and the art of data modeling largely determines the art of designing applications.
')
Of course, a very important place in business applications and occupy processes. Although there is a strong desire (both for us and developers of other platforms for developing business applications) to place greater weight on application design on processes, but the data still remains the most significant aspect of the subject area. And it is on the reflection of the data that the main application model is built.
We make only a small reservation. Data here refers to data accompanying processes. That is, it turns out that the processes are also indirectly expressed through the data model.
In the 1C: Enterprise platform, there are mechanisms for reflecting processes, but this is the topic of a separate article.
There are several traditional paradigms for working with data.
First of all - there is a classic relational model. It describes the data as relational tables (usually stored in relational DBMS). This paradigm, though not at all new, is quite relevant.
There is an object paradigm. It describes the data as objects of a programming language and is somehow stored in a database. This can be a relational or object database. In the first case, the simulation capabilities are determined by the DBMS , in the second case, the ORM used.
There are also techniques and approaches that are used less frequently (when creating business applications). For example, an approach based on semistructured data.
Now, in fact, about the approach that we have chosen for the 1C: Enterprise platform. For him there is no officially accepted name. Let's call it “the type model of applied objects”. The essence of the approach is that the platform offers the developer a certain set of types of application objects. Each type is intended to be reflected in the application model of a certain category of domain entities. The application developer, when reflecting the domain of the problem being solved in the application model, should select the appropriate types of objects and use them to describe the data model. In fact, while he describes not only the data model, but, in many respects, the model of the application itself. But more on that later.
What is the type of application object?
This is some kind of template embedded in the platform (it can also be considered an abstract class), defining many different aspects of working with the essence of the domain.
Types of application objects appear during development (in design-time) and during system operation (in run-time). In design-time, this is a meta-model for describing objects in metadata and classes for manipulating data in a program model. In run-time these are various aspects of the system behavior when working with objects of this type. For example, the behavior of the lock mechanism.
In 1C: Enterprise there are several types of application objects.
For example, take three types:
- Directories
- Documents
- Accumulation registers
Directories are intended to reflect in the system some conditionally permanent information (lists of employees, goods, clients ...).
Documents reflect some of the events of the subject area (sale, recruitment, transfer of money to the bank). Sometimes they are called by the name of printed forms (“payment order”, “order for admission to work”, ...). But this is just for convenience of understanding. In fact, this is exactly the type of event, not the printed form.
Accumulation registers are intended to be reflected in the application of some accounting system. For example, accounting storage of cash or goods in warehouses.
Let's see what all the same is included in the "set" of opportunities provided by the types of application objects
First of all, of course, the type of application object describes the data model and provides data mapping to the relational storage model. But this is only a small part of what it defines.
For example, for reference:
- there are several standard details (fields), embedded directly into the platform (reference-identifier, code, name, reference to the parent for the hierarchical directory, ...)
- You can describe your (arbitrary) details (fields)
- You can describe the tabular parts, which are closely related entities (containment) or else they can be considered as nested tables.
For a document, it looks like, but there is a standard attribute, Date, which reflects the position of the event relative to other events on the time axis, as well as the “Done” feature, which determines whether the document is reflected in the accounting system or is a draft.
For the register of accumulation of the field are divided into dimensions, resources and details. Dimensions describe the coordinate system of the accounting model (for example, product, warehouse), resources - indicators (for example, quantity, sum), details - just additional fields (which do not affect the accounting model, but commenting on the movement records).
Why do we operate with types of application objects, and do not operate, for example, with just tables (or just entities)?
This is a very important point. Tables have many advantages. They are closer to the simplest modeling in the relational model; they do not limit the developer to the framework of the types inherent. But the tables and do not give those opportunities that gives us the chosen approach.
The essence of the approach we have chosen is (to put it in simple terms) that in our approach the system (platform) itself “knows a lot of things” about the objects described and “knows a lot of things with them”. Based on this knowledge and skills, the system automatically provides more than a dozen different mechanisms that work directly or indirectly with these objects. That is, it turns out that the application developer chooses the type of object and describes a specific object, and the platform, knowing the type and description of a specific object, provides many different useful functions and mechanisms. This is achieved due to the fact that the semantics of objects of a given type are defined at the level of an object type (the object's purpose is “large”), and the metadata model allows specifying the semantics of a specific object due to various properties and specialized models describing various aspects of life activity.
We list only some of them:
- First of all, of course, this is the creation of data structures for storage and the automatic transformation of the structure when the model changes.
- A set of classes in the object model for manipulating data (read, write, search)
- Object-relational mapping mechanism
- A set of typical data processing procedures. For example, for documents, this is automatic numbering, for a register, this is a calculation of totals, getting a slice of residuals at a particular point in time, etc.
- Reflection in the system of rights. Since the system knows about the purpose of the object, it knows what rights will be relevant for it
- Visualization (reflected in the interface). Again, knowing the purpose and role of objects, the system itself constructs both commands in the application interface for accessing objects of this type, forms for viewing and editing, and commands for various actions with the object.
- Data exchange. Based on the knowledge of data semantics, the platform provides a standard mechanism for asynchronous exchange of modified data both among related applications (distributed base nodes) and between heterogeneous applications (written both in 1C: Enterprise and other technologies)
- Object and transaction locks. In order to properly build a locking system, you need knowledge of data assignment and relationships.
- Mechanism characteristics (additional fields, user-defined)
- Automatically provided REST interface (OData standard)
- Data upload / download to XML, JSON
- In addition, mechanisms such as full-text search, data access logging, etc. automatically work.
The diagram shows not all the platform mechanisms that operate on the basis of application objects, but only some.
In a sense, the types of application objects intersect with the aspect-oriented approach. Since all of the listed opportunities are some predefined aspects that reflect the types of application objects. It can be said that the types of application objects are not just templates, but parameterized templates. Parameterization is carried out by a set of metadata properties. By selecting the property value, the developer parametrizes the template of the selected type of application object and specifies the behavior of the object in a particular aspect. For example, he can select the type of document numbering (within a year, quarter, month ...) and the system will automatically ensure the assignment and control of numbers with a specified frequency.
Types of applied objects provide knowledge of the semantics not only of the entities themselves, but also of the semantics of their interrelationships. For example, there is a standard link between documents and registers, reflecting how events are reflected in the accounting model in the subject area. Having identified such a link, the developer immediately obtains the finished functionality for the joint lifetime of the document and the associated registry entries.
Separately, it is worth mentioning important subject-oriented aspects.
For example, for reference books it is possible to enable hierarchy support with one checkbox. At the same time, the system will provide support for hierarchical directories in everything: in the user interface, in reports, in the object model.
Setting one directory property “Hierarchical Reference” immediately supports hierarchy in the user interface, in reports, in the object model.
For documents, there are opportunities such as journals, combining several types of documents, continuous numbering by periods, etc.
For accumulation registers, the most important possibility is the automatic storage of calculated totals and ready-made virtual tables for access to the results in various sections and taking into account the periodicity.
That is, in essence, an essential part of the universal (typical) mechanisms of the application business logic, characteristic for the relevant data category of the domain, is incorporated into the types of application objects.
It turns out that the developer assembles the application from the objects of the selected types, as from the details of the designer. Moreover, if there are designers with “abstract” parts, then in our designer parts are already with “purpose” - wheels, windows, doors ...
Based on the “Directory” type, the developer builds reference books of products, employees, currencies, clients; based on the type of "Document" - documents "Purchase Order", "Account", "Sales Order", etc.Still it is necessary to say about the methodological value of this approach. All developers operate with a certain set of concepts that helps them to better understand the essence of applications, simplifies communication. Having opened an unfamiliar 1C: Enterprise project, the developer immediately sees familiar concepts and can quickly figure out what role this or that object plays in the system. For example, to understand the essence of the application, it is worth looking at the list of registers - usually it reflects the main purpose of the application. If you open the structure of tables or, moreover, the structure of classes of an unfamiliar application written on tools that operate on tables and classes, then there will be significantly less understanding.
But, more importantly, this approach brings the language of developers and business representatives (or analysts) closer together. About the need for such a language is well said in the book “Subject-oriented design (DDD). Structuring Complex Software Systems ”by Eric Evans. The types of application objects quickly become understandable to non-programmers, and this allows analysts, customers and developers to discuss the main project functionality in the same language. Often you can meet representatives of business or analysts who do not own programming, but can set the task in terms of the types of 1C: Enterprise application objects.
What else is interesting. This approach ensures the continuous development of the system. We add new mechanisms to the platform, and they immediately start working for already existing objects (without the efforts of an application developer or with minimal effort). For example, we recently developed a mechanism for storing data history (versioning) . Since the system knows in general about the semantics of the data, the developer simply tick the box that he wants to store the data history of a specific object, and the platform provides everything that is needed, from storing the history to visualization - displaying the history of changes to the user as various reports. When we previously developed the standard REST interface mechanism (based on the OData standard), a ready-made REST interface immediately appeared in all applications. Developers did not have to modify anything for this.
Why don't we also make “just tables” (in addition to the ready-made types of application objects)? This is a difficult question. We ourselves ask it periodically.
On the one hand, this seems tempting. So we would close all disputable cases where the subject area does not ideally fit into the set of types of application objects we prepared. It was possible to say to the developers - “well, here is just a table for you - and do everything in it as you wish.” But on the other hand, this will lead to the fact that all our standard mechanisms will be “at a loss” - how do they deal with these tables? After all, they will not know the semantics of this data and will not be able to figure out how to work with them correctly. Well, that is, you can work with them "somehow." Strictly speaking, we have such experience in terms of external sources. For external sources, we describe exactly the tables (without specifying the subject orientation). And the system works with them in some universal way - at the same time, some of the functionality is not supported.
For the time being, we still try to refrain from introducing “just tables” in order to ensure the purity of the model and the ability to add new functionality based on the knowledge of the semantics of all data. If some opportunities are not enough, then at first we will still consider how to develop the types of applied objects. But, of course, this is a debatable question, and we will continue to think about it.
Thus, the possibilities that the 1C: Enterprise platform provides in its finished form, and the increase in the level of abstraction that is appreciated by application developers, is largely based on a set of types of application objects. This is one of the most significant differences between 1C: Enterprise and other development tools and one of the main tools that ensures rapid and unified development.
Source: https://habr.com/ru/post/334050/
All Articles