OOBD without OOP

Personally, I do not need to explain what OOP is. I myself think in the first place nouns and only in the second - verbs.
But it’s not about who thinks how; I want to discuss a situation where the rejection of the usual OOP mechanisms simplifies working 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 an LN form, 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 another form, naturally, by calling other methods. Undefined properties will return an empty string.

There is a certain terminological fog regarding document-oriented and object-oriented databases. It is believed that DOBD is NoSql, and class methods should be stored in the DOBD. However, the same LN also kept the other design in the form description database, and at the same time it was considered DBD, which, shortly before death, was ported to relational DB2.

I hope that the fog will not increase if I call the objects stored in the OOBD, documents, and their properties - fields.

An example with a form is easily implemented in OOP:

Create a new class inherited from the base FORM class, redefine several properties and methods. A new document is associated with a specific form if created by the user from the frontend. If it is created programmatically, the FORM property may remain empty; in this case, when opened, the default form will be used.

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, or rather, storing the name of the form class in the document.

OPM connoisseurs may come up with comments. I suggest temporarily forgetting about ORM, and preferably forever.

Move on. Form is an important part of the UI, but the application has other classes that are not connected with the form in any way. For example, the methods and properties used to create the associated object.

When designing a QMS, the Corrective Action object can be created in different ways depending on the base object. The basis of the incident can be both a marriage complaint and a letter from B. Obama, while the methods for creating a new object should differ.

Similarly, and vice versa: a connected object can act on the base object as it sees fit, as its class nature prescribes.

We implement it in OOP:

Create a class LinkRule and inherit classes from it to create related objects.
We create the ResponseRule class and inherit classes from it to influence the base objects.
When saving the document in the database, we can predetermine the future behavior of the object by filling in the fields with the corresponding links.

For clarity, we will call the “LinkRule” field, it will store the names of classes derived from the base class LinkRule.

As a result, we have:

1. If the document has a LinkRule field, it can serve as the basis for the meaningful creation of other objects.
Example: the document has the field {'LinkRule': 'Action'}, - the linked document will be created in the same way as 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 sounds unusual), or it can ask the user what he wants.
3. During operation, the object may change the field {'LinkRule': ['Action', 'Run']} to {'LinkRule': ['Action', 'Stop']}, respectively, the class membership will change. Sometimes people change their gender. For example, they sent an outgoing document from the Ministry of Finance to the Ministry of Education, he got into the database of the Ministry of Finance and became an incoming one. The form remained old (the fields “Signed”, “Visas”, “Contractor”, etc. remained), and habits should change. The mail agent must replace the object’s game rules 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 in it fields:

'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 desired method.

if ( doc.getField("Form") == "Bullgrader" ) 
	uiDoc = new Bullgrader(doc);
// можно сделать и поизящней

Everything is clear, except for one: has the database become object-oriented?

On the one hand, yes. Objects within themselves belong to a particular class and are associated with specific methods. On the other hand, what kind of an OBD is it, such things can be done in a normalized RDBMS, and the use of such mechanisms in ORM will be called conceptual analytics as datase base schizophrenia.

In addition, in the OOBD, the methods themselves must be stored in the database, but this is not the case here.

The proposed mechanism is rather clumsy; when using interpreted languages, it can be made more flexible and convenient by abandoning 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 directories of all the rules:
LinkRules - a set of rules for creating related objects;
ResponseRule - a set of rules that describe the effects on base objects;
Forms - a list of form descriptions;

Rules are a collection of scripts and constants, but you cannot consider them using document methods. 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, I personally prefer to store them in the database, but there is an opinion that everything should be stored as files. It is possible 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 startup and store in memory. This greatly speeds up the work of the programmer and slightly speeds up the application (well, they will all occupy 10 mb or 100 on the server together - I do not mind).

In order to create a rule, you need to fill out a form of 4 fields. This means that you need to develop the 'LinkRule' form, 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 desired rule in the form of text, danger (lr) checks it for malware, exec executes initialization.

    lr = getRule( 'linkRules', doc.linkRule )
    if lr and not danger( lr ):
            exec( lr, globals(), { 'doc' : doc, 'linkedDoc' : linkedDoc } )
        except Exception as ex:
            snd ('setLinkedFields: %s\n%s' % (lr, ex))
            return False

Since forms for most rules differ only in name, you can make one description of the form for several rules:

'Form' : 'Form',
'Name' : ['LinkRule', 'MailRule', 'ResponseRule'],

You can also save on filters by making a categorized 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 this suggests that the center of gravity of the system is sliding towards the description of the rules, i.e. to the settings area. Flexibility is increasing, and most importantly, this architecture allows you to fulfill the vagaries of the customer, without touching the source code of the instrumental part of the system. At the same time, changing and debugging the rules does not even require a server reboot, just reload the directories.

Rules can describe not only the behavior of objects, but also the composition of tables, reporting, buttons on the screen, and much more. And all this is almost without OOP: to work with rules, only objects of one Document class should be stored in the database.

All of the above is not a theory. For those who want to watch and touch, I posted on the network a simple free crm-sova with DBD on SQLite. The owl is written to console her beloved wife after she bought a very uncomfortable CRM and was upset. This is not an advertisement, I don’t give a link, but it’s easy to find. I immediately warn you: from IE does not work, this is a property of the framework.

- Dear, but SQLite cannot do DBD.
- Why do you think so?
- Ask anyone, I asked anyone, - he said that it’s impossible.
- And more arguments?
- Wikipedia says so.
- Yes. It's hard to argue with that.
- Bye.
- Good luck.

Also popular now: