Opened by lichtkind at 2016-05-01 23:24
Das Wichtigste ist beim Serialisieren, den dazu passenden abstrakten Datentyp zu finden. Interessant sind da vor Allem zyklische Strukturen, beispielsweise als ein langkettiger Hash of Hashes. Darin steckt das Muster Entity-Attribute-Value (EAV) und auch eine gewöhnliche INI-Datei ist danach aufgebaut:
Natürlich haben INI-Dateien hinsichtlich Performance ihre Grenzen, aber anderweitig serialisiert ist es für Perl kein Problem, Dateien mit einigen tausend Rekords bei jedem HTTP-Request von der Platte zu lesen. So richtig interessant wird das bei mod_perl oder FastCGI, bspw. für eine Speicherresidente Configuration. Das EAV-Pattern ergibt einheitliche Prozesse für den Zugriff:
und vor Allem macht ein zweckmäßiges Daten-Entwurfsmuster rekursive Serializer überflüssig. Nicht zuletzt kann aus jedem gewöhlichen Array ein assoziatives Array und abstrakt gesehen eine beliebige Struktur erzeugt werden und wer hätte das gedacht: solche Transformationen sind Plattformunabhängig. Z.B. ergeben nicht nur 2 Array-Werte einen Record sonden auch mal 3 oder 4 oder 5 oder... wobei wir mit 3 Werten wieder bei EAV sind $data = { Entity => { Attribute => 'Value' }}
Last but not least: Tabellen mit beliebig vielen Spalten lassen sich unter der Voraussetzung dass es nur einen unique Key gibt, ebenfalls auf EAV abbilden. Auf diese Art und Weise werden Anwendungen vom DB-Design unabhängig, allein die Anwendung bestimmt die zum Speichern erforderliche Datenstruktur. Data Acces Layer werden dadurch austauschbar und das mit extrem geringem Zeitaufwand.
Fazit: Serilize Algorithmen sind PL und plattformunabhängig und ob JSON, XML oder sonstwas draus gemacht wird, ist absolut nebensächlich. Viel wichtiger ist die Einigung auf einen bestimmten abstrakten Datentyp.
Letztes Beispiel RPC:
Dem Serverseitigen Parser wird lediglich der Content-Type für den POST mitgeteilt. Die daraus erzeugte Datenstruktur ist stets dieselbe. Also egal ob multipart/form-data, application/json, application/xml, application/eav-binary... für mich war die Integration eines Kommandozeilen Framework in mein Web-Application Framework letztendlich ausschlaggebend dafür, die Verwendung von CGI.pm endgültig zu streichen.
Last edited: 2016-05-03 08:22:09 +0200 (CEST)
Natürlich haben INI-Dateien hinsichtlich Performance ihre Grenzen, aber anderweitig serialisiert ist es für Perl kein Problem, Dateien mit einigen tausend Rekords bei jedem HTTP-Request von der Platte zu lesen. So richtig interessant wird das bei mod_perl oder FastCGI, bspw. für eine Speicherresidente Configuration. Das EAV-Pattern ergibt einheitliche Prozesse für den Zugriff:
Code (perl): (dl
)
1 2
$title = $self->eav('title'); # Getter $self->eav('title', 'Neuer Titel'); # Setter
und vor Allem macht ein zweckmäßiges Daten-Entwurfsmuster rekursive Serializer überflüssig. Nicht zuletzt kann aus jedem gewöhlichen Array ein assoziatives Array und abstrakt gesehen eine beliebige Struktur erzeugt werden und wer hätte das gedacht: solche Transformationen sind Plattformunabhängig. Z.B. ergeben nicht nur 2 Array-Werte einen Record sonden auch mal 3 oder 4 oder 5 oder... wobei wir mit 3 Werten wieder bei EAV sind $data = { Entity => { Attribute => 'Value' }}
Last but not least: Tabellen mit beliebig vielen Spalten lassen sich unter der Voraussetzung dass es nur einen unique Key gibt, ebenfalls auf EAV abbilden. Auf diese Art und Weise werden Anwendungen vom DB-Design unabhängig, allein die Anwendung bestimmt die zum Speichern erforderliche Datenstruktur. Data Acces Layer werden dadurch austauschbar und das mit extrem geringem Zeitaufwand.
Fazit: Serilize Algorithmen sind PL und plattformunabhängig und ob JSON, XML oder sonstwas draus gemacht wird, ist absolut nebensächlich. Viel wichtiger ist die Einigung auf einen bestimmten abstrakten Datentyp.
Letztes Beispiel RPC:
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
D:\>.pl RPC
Remote CMD auf dem Host
--attribute, -a: Zeigt Attribut+Value einer Entity in Konfiguration
--base, -ba: Name der Datenbank für Option --sql
--binary, -bi: Erzeuge die Konfiguration als Binary
--cmd, -c: Freies Kommando im aktuellen Verzeichnis
--dump, -d: Dump Response Object
--entity, -e: Zeigt Attribute einer Entity in Konfiguration
--files, -f: Lokale Dateien für Upload
--head, -he: HEAD Request auf URL
--host, -ho: example.com
--request, -r: HTTP Request auf den angegebenen URL oder auf alle URLs
--sql, -s: SQL Anweisung String oder Datei, erfordert --base
--urls, -u: Listet URLs in Konfiguration
Dem Serverseitigen Parser wird lediglich der Content-Type für den POST mitgeteilt. Die daraus erzeugte Datenstruktur ist stets dieselbe. Also egal ob multipart/form-data, application/json, application/xml, application/eav-binary... für mich war die Integration eines Kommandozeilen Framework in mein Web-Application Framework letztendlich ausschlaggebend dafür, die Verwendung von CGI.pm endgültig zu streichen.
Last edited: 2016-05-03 08:22:09 +0200 (CEST)