CN1322418C - System for realizing object continuous service and method thereof - Google Patents

Abstract

The invention relates to object persistent service, and discloses a system and method for realizing object persistent service, which makes the realization of object persistent service simpler and greatly reduces the development workload. The system and method for realizing object continuous service use generic algorithms to summarize the common framework of database operation routines and define them in the database operation module; define specific attributes in the service module and register them in the basic module; according to the database operation The call of the module realizes the specific database query language organization in the basic module, and the data exchange between the attribute and the database table in the service module.

Description

System and method for realizing persistent object service

technical field

The invention relates to object persistence service, in particular to the realization of object persistence service.

Background technique

With the advent of the information age, the application of the network has penetrated into every aspect of people's lives. The sharp increase in the amount of data on the network puts forward higher and higher requirements for the management of network data.

At present, the development of network management software mostly adopts the three-tier architecture of client/server mode, including client, server and relational database (Relational DataBase, RDB for short). On the one hand, the server is connected to the client through the communication platform; on the other hand, the RDB is manipulated through the database middleware. The task model faced by the server is an object-oriented model, which accepts standard C++ objects as the input of the task, and returns the corresponding standard C++ object as the result after completing the task processing. However, the data model that the server needs to manipulate during the execution of tasks is a relational model, and its manipulation method is process-oriented.

Due to the difference between the object-oriented model of the task and the relational model of the database, the data conversion must be completed in the code of the task in the application. In the database interface (DataBase Interface, referred to as DBI) function, the usage is process-oriented, and many very similar functions appear in the code. Data model conversion and routine calls to actual database operations are not directly related to the transactions to be completed by our tasks, but they occur repeatedly in large numbers, and the results are:

First, the code redundancy is greatly increased, and a considerable proportion of the code is used for data model conversion, which greatly increases the workload of development.

Second, when developing a task, in addition to understanding the transaction logic of the task, the developer must not only master its task model, but also master the storage model of the relational database, as well as the model conversion between them, which greatly increases development difficulty.

Third, in the current development mode, data model conversion and database manipulation are completely explicit. DBI functions are full of hard-coded relational database manipulation. The relational schema of relational databases (including table names and column names) It is tightly coupled with the code logic, making the later maintenance of the system extremely difficult. For high-end network management programs, system maintainability is particularly important due to frequent changes in user requirements.

All in all, in most network management systems, the relational model is often manipulated in a process-oriented manner, while the task model is an Object-Oriented (OO) model; the difference between the two models makes the process-oriented In the coding of the system, only explicit model conversion can be performed, and the relational database can be manipulated explicitly, which is the root cause of the above-mentioned problems. For this problem, there are generally two solutions:

One approach, shown in Figure 1, appropriately separates semantic representation from routine algorithms. The solution consists of two levels, object-oriented modeling of persistent objects and mapping of object models to relational databases. The user first establishes an appropriate persistent object model according to the business logic, and explicitly establishes a one-to-one corresponding "knowledge base" object for each specific persistent object. The persistent object completes the necessary semantic definition, and the corresponding "knowledge base" object The actual manipulation of the underlying RDB (such as insert, update, delete, select, etc.) is done explicitly through the database tools (DBTools for short).

Another method is shown in Figure 2, and many third-party products have already adopted this solution. The starting point of this scheme is that everything starts from object modeling. Users use Object Definition Language (ObjectDefine Language, ODL for short) to build the data model of Object-OrientedDataBase (OODB for short), and then call the corresponding compiler to compile and generate The stub code of the C++ persistent object and the establishment of the database script. The so-called stub code here means that the ODL compiler translates the files we write in ODL into C++ code, and translates the classes we write in ODL into C++ classes. The declaration and implementation code of this class are corresponding C++ stub codes. Using the stub code as a framework, coupled with appropriate business logic, it becomes a sustainable object in the system, thereby manipulating the relational database; and the management of the relational database is in charge of a special object manager. The system calls the persistent object at runtime, and the object storage is completed by the persistent object itself. In this way, during system development, developers can only see the layer of sustainable objects, and fully realize the object-oriented encapsulation of the relational model.

In actual application, the above-mentioned solution has the following problems: for the prior art solution 1, the actual amount of code writing has not been reduced, the phenomenon of code redundancy still exists, and the situation that the system is difficult to maintain and expand has not been improved.

For the second prior art solution, the workload of re-using OODB with ODL is too large, and the development is difficult. For most small and medium-sized software companies, it is unrealistic to develop and realize by themselves.

The main reason for this situation is that the problem in the actual application of the prior art solution 1 is that the call to the actual database operation adopts explicit modeling and explicit mapping, which inevitably cannot simplify the code. The maintainability and scalability of the system are also constrained.

The reason for the problems in the actual application of the prior art solution two is that the solution requires the establishment of ODL and the implementation of an ODL compiler for translating the Interface Definition Language (Interface Definition Language, referred to as "IDL") into corresponding C++ codes and Relational Database Script, an object manager built on top of relational databases. The writing of these codes is very huge in terms of workload, and cannot be accepted by most small and medium-sized software companies.

Contents of the invention

In view of this, the main purpose of the present invention is to provide a system and method for realizing object persistent service, which makes the realization of object persistent service simpler and greatly reduces the development workload.

In order to achieve the above purpose, the present invention provides a system for realizing object persistence service, which includes a database operation module, a sustainable object basic module and a plurality of sustainable object service modules, wherein,

The database operation module is used to realize a unified database operation routine through a generic algorithm;

The sustainable object basic module is used to receive and register the semantics reported by the sustainable object service module, complete the organization of specific database operation statements according to the call of the database operation module, and complete the data exchange between attributes and said database table fields associated therewith;

The sustainable object service module is used to define its own attributes and the method of associating the attributes with database table fields according to the sustainable object basic module, for the database operation module to read.

Wherein, the database operation routine includes one or any combination of query, addition, modification, deletion, block read and block write to the database.

The sustainable object basic module also includes a proxy submodule and a field exchange submodule, wherein,

The agent sub-module is used to receive and register the semantics reported by the sustainable object service module;

The field exchange sub-module is used to complete the organization of specific database query statements, and complete the data exchange between the attributes of the sustainable object service module and the associated database table fields.

The system is applicable to network management of communication systems.

The present invention also provides a method for realizing object continuous service, comprising the following steps:

Define its own attributes in the sustainable object service module and how to associate the attributes with database table fields, and report to the sustainable object basic module;

The sustainable object basic module receives and registers the semantics reported by the sustainable object service module;

When performing database operations, the database operation module invokes corresponding database operation routines implemented by generic algorithms, and uses the semantics registered in the sustainable object basic module to complete specific database operation statements;

Execute the specific database operation statement to complete the data exchange between the attributes of the sustainable object service module and the associated database table fields.

Wherein, the database operation routine includes one or any combination of query, addition, modification, deletion, block read and block write to the database.

The method is applicable to network management of communication systems.

The method also includes the steps of:

Construct the database table structure corresponding to the sustainable object service module.

This technical solution has obvious beneficial effects, that is, the technical solution of the present invention introduces the concept of persistence layer, so that the routine operation process of the database can be handled uniformly, which facilitates the development and maintenance of the code; and solves the problem of task mode, process For the problem of schema mismatch, the POS module is used to carry out object-oriented encapsulation of process-oriented database operations, so that programmers can easily establish corresponding sustainable object models according to the task model.

The whole set of POS system realized in this way makes ordinary objects become sustainable objects by adding a few lines of semantic registration codes. It is completely unnecessary to implement an extremely complicated ODL compiler, so that programmers only need to operate on these objects. There is no need to directly face the relational database, which greatly reduces code redundancy and reduces the workload and intensity of development.

In practical application, the technical solution of the present invention provides an easy implementation for small and medium-sized software enterprises when they develop network management systems, and they are faced with the contradiction of manipulating the relational model in a process-oriented manner and using the object-oriented model and the task model as the task model. The solution is conducive to the business expansion of small and medium-sized enterprises in network management.

Description of drawings

Fig. 1 is a structural schematic diagram of the prior art solution one;

Fig. 2 is the structural representation of prior art scheme two;

FIG. 3 is a schematic diagram of the design flow of a system for implementing persistent object services according to an embodiment of the present invention;

FIG. 4 is a schematic structural diagram of a persistent object service according to an embodiment of the present invention;

Fig. 5 is a schematic diagram of POS implementation according to an embodiment of the present invention.

Detailed ways

In order to make the object, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings.

The basic idea adopted by the present invention is to summarize routine database manipulation processes such as insertion, update, deletion, selection, and reading into common algorithms, and these algorithms put forward certain semantic requirements for the manipulated persistent objects. In this way, it is only necessary to define the semantics of persistent objects and carry out structural modeling to form OODB. Trying to define a good algorithm to make it convenient to manually build the OODB model is a key to this solution.

Therefore, the technical solution of the present invention provides a separate POS layer. The starting point of this method is substantially different from existing commercial products in the industry, such as Power Tier, versant, etc. These existing products rely on the ODL compiler to translate the object model created by the programmer with ODL into C++ code. The final object code has no essential difference from manual hard coding, but is automatically generated by the compiler. The method of the present invention is to design a whole set of systems for realizing POS, so that ordinary objects can be changed into sustainable objects only by adding a few lines of semantic registration codes, and it is completely unnecessary to implement an extremely complicated ODL compiler.

After introducing the POS layer, the system is divided into four layers: business layer, OODB (which is represented as a sustainable object tree, and each node in the tree is a persistent object), POS layer, and object storage layer (here RDB). Due to the realization of OODB, the following technical problems must be realized. 1. The most common way to model sustainable object structures is to build an object tree with a root object that has no specific transaction meaning as the root node. The modeling here should be explicit modeling. 2. Adjust the database design so that the organization of relational tables is structurally integrated with the sustainable object model. 3. Establish OODB, external access interface, the interface method should imitate the class factory in the design pattern, and each class is a class factory of its subclass. 4. Establish POS to realize the mapping from OODB to relational database. However, the first three items are all based on the realization of the fourth item. Therefore, it can be seen that the key of the technical solution of the present invention is not to establish OODB, but to establish a set of relatively complete facilities for establishing OODB. The core of this facility It is POS.

The design process of an embodiment of the solution of the present invention will be further described below with reference to FIG. 3 . Before using this process, it is first necessary to develop a persistent object model and a common persistent service layer for the original network management software, and adjust the structured query language (Structured Query Language, referred to as SQL), so that the database tool supports continuous services manipulation.

First execute step 100 , establish a persistent object according to the requirements of business logic and the persistent object model, and then enter step 110 . It should be noted that object persistence is a programming technology, also known as object persistence, which realizes the persistence characteristics of objects, that is, saves the objects in permanent places such as files and databases, and will not be lost when the process exits .

Then execute step 110, use the newly established persistent object to manipulate POS, and then enter step 120. It should be noted that POS services are provided by the previously developed general persistent service layer.

Next, step 120 is executed to manipulate the original database tool through the persistent object service, and then step 130 is executed to complete the operation on the relational database by using the database tool. These database tools are controlled by POS, and there is no difference in the operation of relational databases from general database tools.

It should be pointed out that the core idea of the technical solution of the present invention is to design a whole set of POS system. Class (CPersistentObject), the parent class contains some general semantics such as Object Identity (OID for short), and each specific class (CConcretPerObject) defines its own specific semantics again, such as query conditions, nested queries Sub SQL and more. A "wrapper" (CPerObjWraper) interprets the semantics uniformly, so that the parent class and subclasses can determine a certain degree of flexibility in the SQL framework; at the same time, the three subclasses CSelectPerObjWraper, CUpdatePerObjWraper and CDeletePerObjWraper of the class CPerObjWraper further expand it respectively, The function has been refined. The persistent object also provides an interface to fill in SQL parameters at runtime. Through the above three levels, the unity of flexibility and ease of use is ensured, so as to simplify the complexity of model definition.

The persistence work of the sustainable object is completed by three objects. CAAlgorithms provides the routine operation process of the relational database, and the persistent object CConcretPerObject contains its own necessary semantics, which are provided in an object-oriented manner. CPerObjWraper wraps a layer outside the persistent object CConcretPerObject, which interprets the semantics of persistent objects and reports the semantics for database operations to CAAlgorithms.

After introducing the POS layer, the system is divided into four levels: business layer, OODB (its appearance is a sustainable object tree, and each node in the tree is a persistent object), POS layer, and object storage layer (here RDB ). Due to the realization of OODB, the following technical problems must be realized. 1. The most common way to model sustainable object structures is to build an object tree with a root object that has no specific transaction meaning as the root node. The modeling here should be explicit modeling. 2. Adjust the database design so that the organization of relational tables is structurally integrated with the sustainable object model. 3. Establish OODB, external access interface, the interface method should imitate the class factory in the design pattern, and each class is a class factory of its subclass. 4. Establish POS to realize the mapping from OODB to relational database. However, the first three items are all based on the realization of the fourth item. Therefore, the key of the technical solution of the present invention is not to establish OODB, but to establish a set of relatively complete facilities for establishing OODB. The core of this facility is POS.

As shown in Figure 5, the internal structure of the POS system is mainly composed of three parts: database operation module, sustainable object basic module and multiple sustainable object service modules. In an implementation of the present invention, the database operation module is mainly realized by a generic algorithm, the sustainable object base module is an object generated by a base class called CperBase, and the sustainable object service module is a specific POS object, which generates The concrete POS class of these POS objects is inherited from CPerBase. The generic algorithm manipulates the specific POS class, and the specific POS class inherits from CPerBase. CPerBase interprets and stores the semantics of the specific POS class and reports these semantics to the generic algorithm.

Generic algorithms are separated from specific types and specific data structures, so that they can adapt to and generalize types as much as possible. The algorithm itself is only to realize the logical essence that the algorithm needs to express and not to be used as the implementation details of various data structures. interfered with. This means that a generic algorithm actually has two parts: the actual instructions that describe the algorithm's essential logic, and a set of requirements that correctly specify the properties that its parameter types must satisfy. The core is that abstract conditions become the core of the programming process, thus replacing the core position of types in OO. It is precisely because types are not the focus of consideration that types have become the coat of abstract conditions, so this kind of program thinking is called generic. The idea is to generalize the type. In this system, general query, increase, change, delete and BulkRead/BulkWrite operations are realized by several template functions. Each generic algorithm manipulates specific objects and obtains the semantics of GetSelecter, GetInserter, GetUpdater, GetDeleter, and Read at runtime to achieve general database operations.

These objects are mapped to corresponding table records, attributes are mapped to record fields, and sequences of objects are mapped to tables. The operations of the generic algorithm are divided into table-level operations and record-level operations. Table-level operations include select (query), bulkread (block read), bulkwrite (block write) and other operations; record-level operations: including insert (insert), update (update), delete (delete) operations, are for a specific An operation on an object. There is a principle in the persistent object implementation strategy. After it is instantiated through table-level operations, it is a "Smart object" that can change its own state, self-destruct, and complete persistent operations by itself.

By analyzing the generic algorithm, it is possible to find the minimum set of semantics that a persistent object must provide. It should be pointed out that when determining the semantics, we should use the template method in the behavior mode in the design mode, and define a complete virtual method for assembling SQL in the parent class of the persistent object, such as: GetColumnName, GetTableName, GetWhereCondition, GetOrderByCondition, and so on. Specific persistent objects are appropriately and selectively overloaded when modeling, so as to achieve the unity of flexibility and ease of use.

The specific POS class defines its own attributes and the method of associating the attributes with database table fields for interpretation by generic algorithms.

The CPerBase class is the core of POS. The parent class of each specific POS class uniformly stores the semantics of specific POS objects and provides interfaces for generic algorithm calls. It stores a CProxy class and a CFieldExchange class inside. The CProxy class is responsible for interpreting and storing the semantics of each specific POS class. The CFieldExchange class is responsible for pouring the information read from the database into the attributes of the POS class or pouring the attributes of the POS class into in the database. The role of CPerBase is actually equivalent to a register. The specific POS class registers with it when constructing its object. The generic algorithm searches from the register when manipulating the POS object. If it is not found, the relevant registration is performed. In actual implementation, the technical solution of the present invention solves two specific technologies: how to break the object access control barrier and how to make the collection class vector identify heterogeneous data types. For the first technique, since the ClassObject is not known in the CPerBase class, the ClassObject.m_Attrib method cannot be used. As for the second technique, the solution of the present invention provides a default situation, that is, a vector can only store variables of one data type.

The workflow of the above-mentioned system for implementing persistent object services is as follows:

Define its own attributes in the sustainable object service module and the method of associating the attributes with database table fields, and report to the sustainable object basic module.

The sustainable object basic module receives and registers the semantics reported by the sustainable object service module. Registration includes both interpretation and storage.

When performing database operations, the database operation module invokes the corresponding database operation routines implemented by generic algorithms, and uses the semantics registered in the sustainable object basic module to complete specific database query statements. For example, when a delete operation is required, the database operation module only has the framework implemented by the generic algorithm, and cannot complete the specific Sq1 statement. It is necessary to call the sustainable object basic module, which registers the details required to complete the specific Sq1 statement, according to These details can complete the formation of the specific Sq1 statement.

Execute specific database query statements to complete the data exchange between the attributes of the sustainable object service module and the associated database table fields. The specific way of data exchange is defined in CperBase.

Although the present invention has been illustrated and described with reference to certain preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein, and without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (8)

1. a system that realizes the service of object ensured sustained development is characterized in that, comprises database manipulation module, sustainableization object basic module and a plurality of sustainableization objects services module, wherein,

Described database manipulation module is used for realizing unified database manipulation routine by general type algorithm;

Described sustainableization object basic module is used to receive and register the semanteme that described sustainableization objects services module reports, finish concrete data base manipulation statement tissue according to calling of described database manipulation module, finish the attribute of described sustainableization objects services module and the exchanges data between the described database table field related with it;

Described sustainableization objects services module is used for reading for described database manipulation module according to described sustainableization object basic module definition self attributes and this attribute and database table field correlating method.

2. the system of realization object ensured sustained development according to claim 1 service is characterized in that, described database manipulation routine comprises that inquiry, increase, change, deletion, piece to described database read and piece a kind of or its combination in any in writing.

3. the system of realization object ensured sustained development service according to claim 1 is characterized in that described sustainableization object basic module also comprises acts on behalf of submodule and field recon module, wherein,

The described submodule of acting on behalf of is used to receive and register the semanteme that described sustainableization objects services module reports;

Described field recon module is used to finish concrete query sentence of database tissue, finishes the attribute of described sustainableization objects services module and the exchanges data between the described database table field related with it.

4. the system of realization object ensured sustained development service according to claim 1 is characterized in that described system can be applicable to the network management of communication system.

5. realize object ensured sustained development service method for one kind, it is characterized in that, comprise following steps:

Definition self attributes and this attribute and database table field correlating method in sustainableization objects services module, and be reported to sustainableization object basic module;

Described sustainableization object basic module receives and registers the semanteme that described sustainableization objects services module reports;

When carrying out database manipulation, the associated databases procedure routine that the database manipulation module invokes realizes by general type algorithm, and use the semanteme of registering in the described sustainableization object basic module to finish concrete data base manipulation statement;

Carry out described concrete data base manipulation statement, finish the exchanges data between the attribute of described sustainableization objects services module and the described database table field related with it.

6. realization object ensured sustained development service method according to claim 5 is characterized in that, described database manipulation routine comprises that inquiry, increase, change, deletion, piece to described database read and piece a kind of or its combination in any in writing.

7. realization object ensured sustained development service method according to claim 5 is characterized in that described method can be applicable to the network management of communication system.

8. realization object ensured sustained development service method according to claim 5 is characterized in that described method also comprises following steps:

Structure and the corresponding database table structure of sustainableization objects services module.