OOBD ohne OOP

Persönlich muss ich nicht erklären, was OOP ist. Ich selbst denke in erster Linie an Substantive und nur an die zweiten Verben.
Aber es geht nicht darum, wer wie denkt. Ich möchte eine Situation diskutieren, in der die Ablehnung der üblichen OOP-Mechanismen das Arbeiten mit Objekten vereinfacht.

Als Beispiel können Sie sich an das gute Wort Lotus Notes erinnern, in dem der Name des Formulars im Dokument gespeichert war. Beim Erstellen eines LN-Formulars wird eine neue UI-Klasse beschrieben, in der Sie Eigenschaften hinzufügen und Methoden überschreiben können (Queryopen, Postsave usw.). Gleichzeitig ist ein neues Objekt, das mit diesem Formular erstellt wurde, nicht mit dem Vererbungsmechanismus verknüpft. Ein Formular ist eine Eigenschaft eines Objekts, und in LN gibt es einen "SwitchForm" -Befehl, mit dem Sie ein Objekt mit einem anderen Formular öffnen können, indem Sie natürlich andere Methoden aufrufen. Undefinierte Eigenschaften geben eine leere Zeichenfolge zurück.

In Bezug auf dokumenten- und objektorientierte Datenbanken besteht ein gewisser terminologischer Nebel. Es wird angenommen, dass DOBD NoSql ist und Klassenmethoden in DOBD gespeichert werden sollten. Derselbe LN behielt jedoch auch den anderen Entwurf in der Formularbeschreibungsdatenbank bei, und gleichzeitig wurde er als DBD betrachtet, der kurz vor seinem Tod auf relationales DB2 portiert wurde.

Ich hoffe, dass der Nebel nicht zunimmt, wenn ich die im OOBD gespeicherten Objekte, Dokumente und deren Eigenschaften - Felder aufrufe.

Ein Beispiel mit einem Formular lässt sich in OOP leicht implementieren:

Erstellen Sie eine neue Klasse, die von der Basis-FORM-Klasse geerbt wurde, und definieren Sie mehrere Eigenschaften und Methoden neu. Ein neues Dokument ist einem bestimmten Formular zugeordnet, wenn es vom Benutzer über das Frontend erstellt wurde. Wenn es programmgesteuert erstellt wird, bleibt die FORM-Eigenschaft möglicherweise leer. In diesem Fall wird beim Öffnen das Standardformular verwendet.

Das heißt Wir bestimmen das visuelle Verhalten des Objekts nicht, indem wir der Klasse Methoden hinzufügen, sondern indem wir im Objekt einen Link zu dem Formular speichern, in dem diese Methoden beschrieben sind, oder indem wir den Namen der Formularklasse im Dokument speichern.

OPM-Kenner können sich Kommentare einfallen lassen. Ich schlage vor, ORM vorübergehend und am besten für immer zu vergessen.

Mach weiter. Formular ist ein wichtiger Teil der Benutzeroberfläche, aber die Anwendung verfügt über andere Klassen, die in keiner Weise mit dem Formular verbunden sind. Zum Beispiel die Methoden und Eigenschaften, mit denen das zugeordnete Objekt erstellt wurde.

Beim Entwerfen eines QMS kann das Korrekturmaßnahmenobjekt abhängig vom Basisobjekt auf verschiedene Arten erstellt werden. Die Grundlage des Vorfalls kann sowohl eine Heiratsbeschwerde als auch ein Brief von B. Obama sein, wobei sich die Methoden zur Erstellung eines neuen Objekts unterscheiden sollten.

Ähnlich und umgekehrt: Ein verbundenes Objekt kann auf das Basisobjekt einwirken, wie es die Klassennatur vorschreibt.

Wir implementieren es in OOP:

Erstellen Sie eine Klasse LinkRule und erben Sie Klassen davon, um verwandte Objekte zu erstellen.
Wir erstellen die ResponseRule-Klasse und erben Klassen von ihr, um die Basisobjekte zu beeinflussen.
Beim Speichern des Dokuments in der Datenbank können wir das zukünftige Verhalten des Objekts vorgeben, indem wir die Felder mit den entsprechenden Links ausfüllen.

Beispiel:
Aus Gründen der Übersichtlichkeit werden wir das Feld "LinkRule" aufrufen, in dem die Namen von Klassen gespeichert werden, die von der Basisklasse LinkRule abgeleitet sind.

Als Ergebnis haben wir:

1. Wenn das Dokument ein LinkRule-Feld hat, kann es als Grundlage für die sinnvolle Erstellung anderer Objekte dienen.
Beispiel: Das Dokument hat das Feld {'LinkRule': 'Action'}. - Das verknüpfte Dokument wird auf die gleiche Weise erstellt wie das Objekt der Klasse '' Action '"(von der Klasse LinkRule geerbte Aktion).
2. Angenommen, ein Dokument hat ein Feld {'LinkRule': ['Action', 'Run']}. In diesem Fall kann die Anwendung zwei Methoden aufrufen, um das zugehörige Objekt zu initialisieren (zusammengesetzte Erstellung klingt ungewöhnlich), oder den Benutzer fragen, was er will.
3. Während des Betriebs kann das Objekt das Feld {'LinkRule': ['Action', 'Run']} in {'LinkRule': ['Action', 'Stop']} ändern. Die Klassenzugehörigkeit wird geändert. Manchmal ändern Menschen ihr Geschlecht. Zum Beispiel haben sie ein ausgehendes Dokument vom Finanzministerium an das Bildungsministerium geschickt, er wurde in die Datenbank des Finanzministeriums aufgenommen und wurde ein eingehendes Dokument. Die Form blieb alt (die Felder "Unterschrieben", "Visa", "Auftragnehmer" usw. blieben), und die Gewohnheiten sollten sich ändern. Der Mailagent muss die Spielregeln des Objekts ersetzen, die in der Klasse angegeben sind, die im Feld "MailRule" dieses Objekts angegeben ist. Der Mail-Agent hält sich auch an die Regeln, die aus der Basisklasse MailRule stammen.

In diesen Feldern befindet sich ein Dokument:

{
'UUID' : '301D8348DEE65E9B3C5C5D3DF9864CF2',
'Form' : 'Bullgrader',
'LinkRule' : ['Action', 'Run'],
'ResponseRule' : 'Eight8',
'MailRule' : 'Mailware',
…,
еще много разных полей,
…
}


Und es gibt eine Anwendung, in der alle notwendigen Klassen beschrieben werden.
Die Anwendung weiß, was mit diesen Feldern zu tun ist: Sie müssen ein Objekt der entsprechenden Klasse erstellen, das Dokument an dieses übergeben und die gewünschte Methode aufrufen.

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


Mit einer Ausnahme ist alles klar: Ist die Datenbank objektorientiert geworden?

Einerseits ja. Objekte an sich gehören zu einer bestimmten Klasse und sind bestimmten Methoden zugeordnet. Was für eine Art von OBD ist es andererseits, solche Dinge können in einem normalisierten RDBMS durchgeführt werden, und die Verwendung solcher Mechanismen in ORM durch konzeptionelle Analysten wird im Allgemeinen als Datenbank-Schizophrenie bezeichnet.

Außerdem müssen in der OOBD die Methoden selbst in der Datenbank gespeichert werden, was hier jedoch nicht der Fall ist.

Der vorgeschlagene Mechanismus ist ziemlich umständlich: Wenn interpretierte Sprachen verwendet werden, kann er flexibler und bequemer gestaltet werden, indem Klassen verlassen und Skripte in die Datenbank übertragen werden.

Die Erfahrung hat gezeigt, dass dokumentbezogene Klassen mit Ausnahme der FORM-Klasse sehr einfach sind und in der Regel aus einem Konstruktor und mehreren Eigenschaften bestehen.

Ersetzen Sie das Wort KLASSE durch die REGEL. In der Datenbank erstellen wir Verzeichnisse aller Regeln:
LinkRules - eine Reihe von Regeln zum Erstellen verwandter Objekte;
ResponseRule - Eine Reihe von Regeln, die die Auswirkungen auf Basisobjekte beschreiben.
Formulare - eine Liste von Formularbeschreibungen;
usw.

Regeln sind eine Sammlung von Skripten und Konstanten, die Sie jedoch mit Dokumentmethoden nicht berücksichtigen können. Die Anwendung führt das Skript nicht als Objektmethode, sondern als Funktion aus. In diesem Fall wird das Objekt selbst als Parameter übergeben oder in einer Variablen mit einem bestimmten Namen gespeichert.
Die Regeln sind (in der Regel) kleine Skripte, ich persönlich bevorzuge es, sie in der Datenbank zu speichern, aber es gibt eine Meinung, dass alles als Dateien gespeichert werden sollte. Es ist so und so möglich.

Die meisten Regeln sind Dokumente mit folgenden Feldern:

{
…,
'Form' : 'LinkRule',
'Name' : 'Action',
'File' : 'linkrule_action.py',
'Rule' : "linkedDoc.sendDa = today()\nlinkedDoc.title = 'Действие'"
}


Für Regeln ist es jedoch wie für andere Verzeichnisse sinnvoll, sie beim Serverstart zu laden und im Arbeitsspeicher zu speichern. Dies beschleunigt die Arbeit des Programmierers erheblich und beschleunigt die Anwendung geringfügig (naja, alle belegen zusammen 10 MB oder 100 MB auf dem Server - das macht mir nichts aus).

Um eine Regel zu erstellen, müssen Sie ein Formular mit 4 Feldern ausfüllen. Dies bedeutet, dass Sie das Formular 'LinkRule' entwickeln, einen Filter für die Auswahl von Regeln erstellen und ein Skript schreiben müssen, um sie beim Start des Servers zu laden.

Das Python-Beispiel veranschaulicht die Initialisierung eines verknüpften Dokuments (linkedDoc) gemäß der im Basisdokument (doc) angegebenen Regel. Die Funktion getRule gibt die gewünschte Regel in Form von Text zurück, danger (lr) sucht nach Malware und führt die Initialisierung durch.

    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


Da sich Formulare für die meisten Regeln nur im Namen unterscheiden, können Sie eine Beschreibung des Formulars für mehrere Regeln erstellen:

{
…,
'Form' : 'Form',
'Name' : ['LinkRule', 'MailRule', 'ResponseRule'],
…
}


Sie können auch Filter einsparen, indem Sie eine kategorisierte Darstellung der Regeln erstellen.

In einem der Projekte wurden mehr als 200 Regeln von 11 Typen in der Datenbank gespeichert. Dies ist eine Menge und dies legt nahe, dass der Schwerpunkt des Systems in Richtung der Beschreibung der Regeln gleitet, d. H. zum Einstellungsbereich. Die Flexibilität nimmt zu, und vor allem können Sie mit dieser Architektur die Unklarheiten des Kunden erfüllen, ohne den Quellcode des instrumentellen Teils des Systems zu berühren. Gleichzeitig ist für das Ändern und Debuggen der Regeln nicht einmal ein Neustart des Servers erforderlich. Laden Sie einfach die Verzeichnisse neu.

Regeln können nicht nur das Verhalten von Objekten beschreiben, sondern auch die Zusammensetzung von Tabellen, Berichte, Schaltflächen auf dem Bildschirm und vieles mehr. Und das alles fast ohne OOP: Um mit Regeln zu arbeiten, sollten nur Objekte einer Document-Klasse in der Datenbank gespeichert werden.

Alles oben Genannte ist keine Theorie. Für diejenigen, die zuschauen und anfassen möchten, habe ich im Netzwerk eine einfache, kostenlose crm-sova mit DBD auf SQLite veröffentlicht. Die Eule wurde geschrieben, um ihre geliebte Frau zu trösten, nachdem sie ein sehr unangenehmes CRM gekauft hatte und verärgert war. Dies ist keine Werbung. Ich gebe keinen Link an, aber sie ist leicht zu finden. Ich warne Sie sofort: aus IE funktioniert nicht, das ist eine Eigenschaft des Frameworks.

- Sehr geehrte Damen und Herren, SQLite kann DBD nicht ausführen.
"Warum denkst du so?"
- Frag jemanden, ich fragte jemanden, - er sagte, dass es unmöglich ist.
- Und noch mehr Argumente?
- Wikipedia sagt es.
Ja Es ist schwer damit zu streiten.
- Auf Wiedersehen.
- Viel Glück.

Jetzt auch beliebt: