OOBD without OOP
Personally, I do not need to explain what OOP is. I myself first think of nouns and only the second - with verbs.
But it is not about how one thinks; I want to discuss a situation where the abandonment of familiar OOP mechanisms simplifies work with objects.
As an example, you can recall the good word Lotus Notes, where the name of the form was stored inside the document. Creating the form LN, we thereby describe a new UI class in which you can add properties and override methods (Queryopen, Postsave, etc.). At the same time, a new object created using this form is not associated with the inheritance mechanism. A form is a property of an object, and in LN there is a “SwitchForm” command, with which you can open an object with a different form, naturally, with a call to other methods. In this case, undefined properties will return an empty string.
There is a certain terminological fog in the part of document-oriented and object-oriented databases. It is considered that DOBD is NoSql, and class methods should be stored in OODD. However, the same LN stored in the database the descriptions of forms and other design and at the same time was considered a DBMS, which shortly before his death, ported to relational DB2.
I hope the fog will not increase, if I call the objects stored in OODB documents, and their properties - fields.
')
An example of a form is easily implemented in OOP:
We create a new class inherited from the base FORM class, override several properties and methods. A new document is associated with a specific form if created by a user from the frontend. If it is created programmatically, the FORM property may remain empty; in this case, the default form will be used when opening.
Those. we determine the visual behavior of the object not by adding methods to the class, but by storing in the object a link to the form in which these methods are described, more precisely, we store the name of the form class in the document.
ORM experts may have comments. I propose to temporarily forget about the ORM, and better forever.
Go ahead. The form is an important part of the UI, but the application has other classes that are not related to the form. For example, the methods and properties used when creating a linked object.
When designing the QMS, the “Corrective Impact” object can be created differently depending on the underlying object. The basis of the incident can be both a marriage complaint and B. Obama's letter, and the methods for creating a new object should be different.
Similarly, and vice versa: a bound object can act on a base object as it sees fit, as its class essence dictates.
We implement in OOP:
Create a LinkRule class and inherit classes from it to create related objects.
We create the ResponseRule class and inherit classes from it to affect the base objects.
When saving a document in the database, we can predetermine the future behavior of the object by filling in the fields with the appropriate links.
Example:
For clarity, let's call the field “LinkRule”, it will store the names of classes generated from the base class LinkRule.
As a result, we have:
1. If the document has a LinkRule field, it can serve as a basis for meaningful creation of other objects.
Example: the document has the field {'LinkRule': 'Action'}, - the linked document will be created as ordered by the object of the class "Action" (Action inherited from the class LinkRule).
2. Suppose a document has a field {'LinkRule': ['Action', 'Run']}. In this case, the application can call two methods to initialize the associated object (composite creation - it sounds unusual), or it can ask the user what he wants.
3. During the operation, the object can change the {'LinkRule': ['Action', 'Run']} field to {'LinkRule': ['Action', 'Stop']}, the class membership will change accordingly. Sometimes people change gender. For example, they sent an outgoing document from the Ministry of Finance to the Ministry of Finance, it got into the database of the Ministry of Education and became incoming. The form remained old (the fields “Signed”, “Visas”, “Artist”, etc.) remained, and the habits should be changed. The mail agent must replace the rules of the game for the object as specified in the class specified in the “MailRule” field of this object. The mail agent also plays by the rules originating in the base class MailRule.
There is a document with fields in it:
And there is an application where all the necessary classes are described.
The application knows what to do with these fields: you need to create an object of the corresponding class, pass the document to it and call the required method.
Everything is clear, except for one: has the database become object-oriented?
On the one hand, yes. Objects are stored within themselves belonging to a particular class and are associated with specific methods. On the other hand, what kind of OODB is this, such things can be done in a normalized RDBMS, and conceptual analysts in general will call the use of such mechanisms in ORM general-schizophrenia.
In addition, in OODB methods themselves must be stored in the database, but here it is not.
The proposed mechanism is rather clumsy, using interpreted languages, it can be made more flexible and convenient by discarding classes and transferring scripts to the database.
Experience has shown that document-related classes, with the exception of the FORM class, are very simple, they usually consist of one constructor and several properties.
Replace the word CLASS with the RULE. In the database we create reference books of all the rules:
LinkRules - a set of rules for creating linked objects;
ResponseRule - a set of rules that describe the effects on base objects;
Forms - list of form descriptions;
etc.
Rules are a collection of scripts and constants, but they cannot be considered methods of the document. The application does not execute the script as an object method, but as a function. In this case, the object itself is passed as a parameter or stored in a variable with a specific name.
The rules (as a rule) are small scripts, personally, I prefer to store them in the database, but it is believed that everything should be stored as files. It is possible and so and so.
Most rules are documents with the following set of fields:
Rules, however, like other directories, it makes sense to load at server start and store in memory. This greatly speeds up the work of the programmer and speeds up the application a little (well, they will all take 10 MB or 100 on the server, I don’t feel sorry).
In order to create a rule, you need to fill out a form of 4 fields. This means you need to develop a form 'LinkRule', make a filter for selecting rules, write a script to load them when the server starts.
The Python example demonstrates the initialization of a linked document (linkedDoc) according to the rule specified in the base document (doc). The getRule function returns the necessary rule as text, danger (lr) checks it for maliciousness, exec performs initialization.
Since the forms for most rules differ only in name, you can make one form description for several rules:
Filters can also be saved by making a categorical representation of the rules.
In one of the projects, more than 200 rules of 11 types were stored in the database. This is a lot and it means that the center of gravity of the system is slipping towards the description of the rules, i.e. in the settings area. Flexibility increases, and most importantly, this architecture allows you to execute the vagaries of the customer, without touching the source codes of the instrumental part of the system. At the same time, changing and debugging the rules does not even require rebooting the server; it’s enough to reload directories.
The rules can describe not only the behavior of objects, but also the composition of tables, statements, buttons on the screen and much more. And all this is almost without OOP: to work with the rules, objects of only one Document class should be stored in the database.
All of the above is not a theory. For those who want to see and touch, I posted a simple free crm-sova from DOBD to SQLite. The owl is written to comfort his beloved wife after she bought a very uncomfortable CRM and was upset. This is not an advertisement, I do not give a link, but it is easy to find. Immediately I warn you: from IE does not work, this is a property of the framework.
- Dear, but on SQLite it is impossible to make DOBD.
- Why do you think so?
- Ask anyone, I asked anyone, - he said that it is impossible.
- And the arguments?
- Wikipedia says so.
- Yes. It's hard to argue with that.
- Goodbye.
- Good luck.
But it is not about how one thinks; I want to discuss a situation where the abandonment of familiar OOP mechanisms simplifies work with objects.
As an example, you can recall the good word Lotus Notes, where the name of the form was stored inside the document. Creating the form LN, we thereby describe a new UI class in which you can add properties and override methods (Queryopen, Postsave, etc.). At the same time, a new object created using this form is not associated with the inheritance mechanism. A form is a property of an object, and in LN there is a “SwitchForm” command, with which you can open an object with a different form, naturally, with a call to other methods. In this case, undefined properties will return an empty string.
There is a certain terminological fog in the part of document-oriented and object-oriented databases. It is considered that DOBD is NoSql, and class methods should be stored in OODD. However, the same LN stored in the database the descriptions of forms and other design and at the same time was considered a DBMS, which shortly before his death, ported to relational DB2.
I hope the fog will not increase, if I call the objects stored in OODB documents, and their properties - fields.
')
An example of a form is easily implemented in OOP:
We create a new class inherited from the base FORM class, override several properties and methods. A new document is associated with a specific form if created by a user from the frontend. If it is created programmatically, the FORM property may remain empty; in this case, the default form will be used when opening.
Those. we determine the visual behavior of the object not by adding methods to the class, but by storing in the object a link to the form in which these methods are described, more precisely, we store the name of the form class in the document.
ORM experts may have comments. I propose to temporarily forget about the ORM, and better forever.
Go ahead. The form is an important part of the UI, but the application has other classes that are not related to the form. For example, the methods and properties used when creating a linked object.
When designing the QMS, the “Corrective Impact” object can be created differently depending on the underlying object. The basis of the incident can be both a marriage complaint and B. Obama's letter, and the methods for creating a new object should be different.
Similarly, and vice versa: a bound object can act on a base object as it sees fit, as its class essence dictates.
We implement in OOP:
Create a LinkRule class and inherit classes from it to create related objects.
We create the ResponseRule class and inherit classes from it to affect the base objects.
When saving a document in the database, we can predetermine the future behavior of the object by filling in the fields with the appropriate links.
Example:
For clarity, let's call the field “LinkRule”, it will store the names of classes generated from the base class LinkRule.
As a result, we have:
1. If the document has a LinkRule field, it can serve as a basis for meaningful creation of other objects.
Example: the document has the field {'LinkRule': 'Action'}, - the linked document will be created as ordered by the object of the class "Action" (Action inherited from the class LinkRule).
2. Suppose a document has a field {'LinkRule': ['Action', 'Run']}. In this case, the application can call two methods to initialize the associated object (composite creation - it sounds unusual), or it can ask the user what he wants.
3. During the operation, the object can change the {'LinkRule': ['Action', 'Run']} field to {'LinkRule': ['Action', 'Stop']}, the class membership will change accordingly. Sometimes people change gender. For example, they sent an outgoing document from the Ministry of Finance to the Ministry of Finance, it got into the database of the Ministry of Education and became incoming. The form remained old (the fields “Signed”, “Visas”, “Artist”, etc.) remained, and the habits should be changed. The mail agent must replace the rules of the game for the object as specified in the class specified in the “MailRule” field of this object. The mail agent also plays by the rules originating in the base class MailRule.
There is a document with fields in it:
{ 'UUID' : '301D8348DEE65E9B3C5C5D3DF9864CF2', 'Form' : 'Bullgrader', 'LinkRule' : ['Action', 'Run'], 'ResponseRule' : 'Eight8', 'MailRule' : 'Mailware', …, , … } And there is an application where all the necessary classes are described.
The application knows what to do with these fields: you need to create an object of the corresponding class, pass the document to it and call the required method.
if ( doc.getField("Form") == "Bullgrader" ) uiDoc = new Bullgrader(doc); // … uiDoc.queryOpen(); … Everything is clear, except for one: has the database become object-oriented?
On the one hand, yes. Objects are stored within themselves belonging to a particular class and are associated with specific methods. On the other hand, what kind of OODB is this, such things can be done in a normalized RDBMS, and conceptual analysts in general will call the use of such mechanisms in ORM general-schizophrenia.
In addition, in OODB methods themselves must be stored in the database, but here it is not.
The proposed mechanism is rather clumsy, using interpreted languages, it can be made more flexible and convenient by discarding classes and transferring scripts to the database.
Experience has shown that document-related classes, with the exception of the FORM class, are very simple, they usually consist of one constructor and several properties.
Replace the word CLASS with the RULE. In the database we create reference books of all the rules:
LinkRules - a set of rules for creating linked objects;
ResponseRule - a set of rules that describe the effects on base objects;
Forms - list of form descriptions;
etc.
Rules are a collection of scripts and constants, but they cannot be considered methods of the document. The application does not execute the script as an object method, but as a function. In this case, the object itself is passed as a parameter or stored in a variable with a specific name.
The rules (as a rule) are small scripts, personally, I prefer to store them in the database, but it is believed that everything should be stored as files. It is possible and so and so.
Most rules are documents with the following set of fields:
{ …, 'Form' : 'LinkRule', 'Name' : 'Action', 'File' : 'linkrule_action.py', 'Rule' : "linkedDoc.sendDa = today()\nlinkedDoc.title = ''" } Rules, however, like other directories, it makes sense to load at server start and store in memory. This greatly speeds up the work of the programmer and speeds up the application a little (well, they will all take 10 MB or 100 on the server, I don’t feel sorry).
In order to create a rule, you need to fill out a form of 4 fields. This means you need to develop a form 'LinkRule', make a filter for selecting rules, write a script to load them when the server starts.
The Python example demonstrates the initialization of a linked document (linkedDoc) according to the rule specified in the base document (doc). The getRule function returns the necessary rule as text, danger (lr) checks it for maliciousness, exec performs initialization.
lr = getRule( 'linkRules', doc.linkRule ) if lr and not danger( lr ): try: exec( lr, globals(), { 'doc' : doc, 'linkedDoc' : linkedDoc } ) except Exception as ex: snd ('setLinkedFields: %s\n%s' % (lr, ex)) return False Since the forms for most rules differ only in name, you can make one form description for several rules:
{ …, 'Form' : 'Form', 'Name' : ['LinkRule', 'MailRule', 'ResponseRule'], … } Filters can also be saved by making a categorical representation of the rules.
In one of the projects, more than 200 rules of 11 types were stored in the database. This is a lot and it means that the center of gravity of the system is slipping towards the description of the rules, i.e. in the settings area. Flexibility increases, and most importantly, this architecture allows you to execute the vagaries of the customer, without touching the source codes of the instrumental part of the system. At the same time, changing and debugging the rules does not even require rebooting the server; it’s enough to reload directories.
The rules can describe not only the behavior of objects, but also the composition of tables, statements, buttons on the screen and much more. And all this is almost without OOP: to work with the rules, objects of only one Document class should be stored in the database.
All of the above is not a theory. For those who want to see and touch, I posted a simple free crm-sova from DOBD to SQLite. The owl is written to comfort his beloved wife after she bought a very uncomfortable CRM and was upset. This is not an advertisement, I do not give a link, but it is easy to find. Immediately I warn you: from IE does not work, this is a property of the framework.
- Dear, but on SQLite it is impossible to make DOBD.
- Why do you think so?
- Ask anyone, I asked anyone, - he said that it is impossible.
- And the arguments?
- Wikipedia says so.
- Yes. It's hard to argue with that.
- Goodbye.
- Good luck.
Source: https://habr.com/ru/post/235725/
All Articles