The original intention of DomainModelDescriptor design is to adapt to different types of model definitions that can be written to or read from the database through ObjectiveSQL . There are similar designs in JDK, such as PropertyDescriptor, BeanDescriptor, etc. Its purpose is also to describe the basic elements of Java Bean and Property. Information, but DomainModelDescriptor is an abstract definition in ObjectiveSQL , describing a business model that can be recognized by ObjectiveSQL , which can be a Java Bean or other objects.
In my past projects, in addition to the commonly used Java Bean models that can access the database, there are also some other types of models that also need to be stored in the database. The specific examples are as follows:
Process introduction:
- Usually, when the amount of data is too large, Apache Fluent is used for data caching, and then centralized storage (the amount of data in a single batch exceeds 500,000 rows of records)
- Data needs to be transmitted between different systems, which means that the transmission and storage structure needs to be defined. ProtoBuffer is a more suitable structure definition. It is excellent in terms of scalability, compression and decompression efficiency, so we choose ProtoBuffer for structure definition and data transmission.
- ProtoBuffer has its own data carrier, which is different from ordinary Java Beans. If the data is converted into Java Beans, additional performance overhead will be incurred . ObjectiveSQL can only accept such a model after it is described by DomainModelDescriptor .
The above describes a DomainModelDescriptor scenario. Since the structure of the data model is different in different usage scenarios, ObjectiveSQL fully considers the changes in the scenario, so it abstracts the DomainModelDescriptor to provide necessary meta-information for database access.