3-Tier-Modell

[wodim]

Bei den Schichtmodellen kommt es immer auf den Betrachtungswinkel an. 3tier kann App basierend oder auch über Servergrenzen gehen.

Kann. Sollte aber über Servergrenzen gehen. Finde ich jedenfalls.

Das zeigen auch die entsprechenden Wikipediaeinträge. Daher liegt es immer im Auge des aktuellen Betrachters das richtige Modell zu erspähen. Deswegen ist es manchmal besser sein eigenes Modell zu finden. [...] Finde deinen eigenen Betrachtungswinkel.

Ok, den habe ich gefunden, ich baue mir mein eigenes Modell. Aber eine Verständnisfrage ist noch offen:

Worin liegt der Sinn, mehrere Schichten in einer Anwendung aufzubauen, also letztlich auf jedem Client? (So wie es eben z.B: Laz-n-Tier und tiOPF machen.) Wenn mir einer den erklären kann, dann muss ich den Vorwurf einstecken, ich hätte die Funktionsweise dieser Frameworks nicht verstanden. Aber nur dann.

[af0815]

Worin liegt der Sinn, mehrere Schichten in einer Anwendung aufzubauen, also letztlich auf jedem Client?

Kurze Antwort:
a ) Skalierbarkeit, Wartbarkeit durch Modularität, Testbarkeit,
b ) Kostengründe (Server, Wartung, Backup)
c ) Weil es geht oder gefordert ist


Lange Antwort:
Zum Nachlesen (auf Englisch)
https://tiopf.sourceforge.net/Doc/Conce ... eLayer.pdf
https://web.archive.org/web/19980506085 ... bjects.pdf

tiOPF ist ein persistenz Framework - das auch verschiedene Schichten in einem Programm verwendet. Es geht hier um Betriebssicherheit und Wartung. Nachdem du eine n-tier Lösung suchst, ist tiOPF auch eine Möglichkeit. Und im professionellen Bereich geht es gerade um Betriebssicherheit und Wartung.

Mormot(2) hat wie tiOPF einen Persistezlayer, zusätzlich aber auch einen Buissnessteil der per REST oder Web mit externen Clients arbeiten kann. Siehe auch Kapitel 1 Synopse mORMmot Overview. Das würde genaugenommen besser zu dem passen, was du will. Man kann, wenn man will - entweder einen Fat-Client machen wo alle Schichten in einem konzentriert sind, oder es über mehrere Server strecken, wenn es nötig ist.

Ich habe hier in der Automotive Programme, die nach 10 Jahren auch noch laufen und Wartbar sein müssen. Teileweise ist die Automotive Industrie ähnlich wie die Pharmazie extrem auf Rückverfolgbarkeit getrimmt. Und nein, ich habe mich vor Jahren dazu entschlossen, nicht den Overhead von tiOPF oder Mormot zu verwenden, weil die Anforderungen im Detail zu speziell wurden und durch die nötigen Anpassungen an Produktionsmaschinen zusätzliche Komplexität gebracht hat (Kommunikation mit diversen SPS'sen).

Ach ja, ich würd empfehlen, die Dokumentation zu tiOPF und Mormot zu lesen (Mormot2 ist von Design der Architektur fast gleich wie Mormot, steht aber auch in der Doku, das man die V1 für Überlegungen heranziehen kann).

Hinweis: Zu Laz-n-tier kann ich nichts sagen, keine Ahnung

[Zvoni]

Es gibt einen Punkt, den man nicht ausser acht lassen sollte
https://en.wikipedia.org/wiki/Multitier_architecture

Other considerations
Data transfer between tiers is part of the architecture. Protocols involved may include one or more of SNMP, CORBA, Java RMI, .NET Remoting, Windows Communication Foundation, sockets, UDP, web services or other standard or proprietary protocols. Often middleware is used to connect the separate tiers. Separate tiers often (but not necessarily) run on separate physical servers, and each tier may itself run on a cluster.

Wenn du deinen "Mittelmann" wirklich auf ner separaten Maschine laufen lassen willst, wirst du an genannten "Kommunikations-Methoden" nicht vorbeikommen.
Und siehe da, da sind ja auch schon die erwähnten Sockets und UDP

Heisst: Dein eigentlicher Client (Das, wo der User davor sitzt) wird NIEMALS ein MeinQuery.Dataset erhalten, sondern immer nur "Strings" (Eigenes Format, JSON, was auch immer), welche du dann im Client selbst decoden musst.
Andy hat ja in seiner Antwort ja auch schon REST erwähnt.

Heisst auch: Irgendwelche DB-gebundenen Controls kannste in die Tonne treten.

Alles gesagt: Mittlerweile bin ich bei dem Punkt angekommen, dass wenn du wirklich diese Architektur einsetzen willst, Lazarus/FreePascal das falsche Tool ist.
Würde dann eher in Richtung webbasierte Programmierung schauen

[wodim]

@af0815: Dachte ich's mir doch, du siehst das viiiiiel zu kompliziert.

Hier geht's doch nur um ein paar Patientendaten. Ein paar Strings pro Patient. Die werden bei der Anmeldung erfasst, nach Angaben des Patienten. Aber dann in jeder Abteilung neu, und das soll dann Geschichte sein. (Bei jährlich > 10.000 Pat. schon ein Einsparungspotenzial im Millionenbereich.)

Also was muss mein Server denn können? Ein paar einfache Funktionen ausführen, die den Datentraffic zwischen Datenbank, Objekten in der "Mittelschicht" und Clients realisieren.

Worin liegt der Sinn, mehrere Schichten in einer Anwendung aufzubauen, also letztlich auf jedem Client?

a ) Skalierbarkeit,

Hallo, was mit 10 Datensätzen geht, geht auch mit 1 Mio Datensätzen.

Wartbarkeit durch Modularität, Testbarkeit,

Das ist keine Frage irgendeines Frameworks, sondern meiner "Disziplin": Keinen ungetesteten Spaghetti-Code abzuliefern. Übrigens vertraglich genau geregelt: Abnahme durch den Auftraggeber, Dokumentation, Offenlegung des Quellcodes, ...

b ) Kostengründe (Server, Wartung, Backup)

Ja mei, du kannst dir doch sicher vorstellen, was in so einer Klinik schon alles an Hard- und Software läuft. Da fällt der für meine Lösung
erforderliche "Mehraufwand" überhaupt nicht ins Gewicht. Übrigens: Was kostet ein Linux-Server, und was ein MariaDB-Server da drauf? Genau, Null Komma gar nichts.

c ) Weil es geht oder gefordert ist

Welcher vernünftige Mensch sollte das also fordern?

Betriebssicherheit

Die Lösung ist, wenn sie einmal läuft, genau so sicher wie alles in der Klinik, und dafür ist die IT dort zuständig. Nach der Abnahme nicht mehr mein Problem. Es sei denn, irgendwann kommt doch noch ein Bug hoch, der durch alle Tests geschlüpft ist. Bei dieser vergleichsweise simplen Lösung aber äußerst unwahrscheinlich. Und wenn, ist der schnell gefunden. Auf lebenslanger Gewährleistungsbasis, sozusagen.

[wodim]

Es gibt einen Punkt, den man nicht ausser acht lassen sollte
https://en.wikipedia.org/wiki/Multitier_architecture

Other considerations
Data transfer between tiers is part of the architecture. Protocols involved may include one or more of SNMP, CORBA, Java RMI, .NET Remoting, Windows Communication Foundation, sockets, UDP, web services or other standard or proprietary protocols. Often middleware is used to connect the separate tiers. Separate tiers often (but not necessarily) run on separate physical servers, and each tier may itself run on a cluster.

Wenn du deinen "Mittelmann" wirklich auf ner separaten Maschine laufen lassen willst, wirst du an genannten "Kommunikations-Methoden" nicht vorbeikommen.
Und siehe da, da sind ja auch schon die erwähnten Sockets und UDP

Ja und? Nochmal:

https://stackoverflow.com/questions/307 ... locksocket

Noch nicht getestet, aber so sollte es doch funktionieren?

Heisst: Dein eigentlicher Client (Das, wo der User davor sitzt) wird NIEMALS ein MeinQuery.Dataset erhalten, sondern immer nur "Strings" (Eigenes Format, JSON, was auch immer), welche du dann im Client selbst decoden musst.
Heisst auch: Irgendwelche DB-gebundenen Controls kannste in die Tonne treten.

Und wo liegt da das Problem?

Alles gesagt: Mittlerweile bin ich bei dem Punkt angekommen, dass wenn du wirklich diese Architektur einsetzen willst, Lazarus/FreePascal das falsche Tool ist.

Weißt du, wie ich darauf gekommen bin? Ich glaube, du kommst nicht drauf.

Würde dann eher in Richtung webbasierte Programmierung schauen

Nur, wenn's nicht anders geht.

[wodim]

Worin liegt der Sinn, mehrere Schichten in einer Anwendung aufzubauen, also letztlich auf jedem Client?

a ) Skalierbarkeit,

Hallo, was mit 10 Datensätzen geht, geht auch mit 1 Mio Datensätzen.

Ok, mir ist schon klar, dass du mit "Skalierbarkeit" was anderes meinst. Aber geht mit diesem Modell nicht genau der Vorteil der 3-Tier-Architektur flöten: Die Daten jedes Patienten werden bei der Anmeldung (Erfassung) nicht nur in der Datenbank gespeichert, sondern stehen auch schon für jeden Client in der "Objektschicht" - eben als Eigenschaften eines Objekts der Klasse "Patient". Da sollte sich schon ein Geschwindigkeitsvorteil ergeben, wenn die nächste Abteilung sie nicht erst in vielleicht 1 Mio. Datensätzen suchen muss. Wieder falsch gedacht?

[wodim]

Mormot(2) hat wie tiOPF einen Persistezlayer, zusätzlich aber auch einen Buissnessteil der per REST oder Web mit externen Clients arbeiten kann. Siehe auch Kapitel 1 Synopse mORMmot Overview. Das würde genaugenommen besser zu dem passen, was du will. Man kann, wenn man will - entweder einen Fat-Client machen wo alle Schichten in einem konzentriert sind, oder es über mehrere Server strecken, wenn es nötig ist.

Ok, werde wohl nicht darum herumkommen. *** seufz *** Aber unter deinen Links finde ich "Kapitel 1 Synopse mORMmot Overview" nicht. Zeigst du es einem Blinden mal?

[theo]

Aber unter deinen Links finde ich "Kapitel 1 Synopse mORMmot Overview" nicht. Zeigst du es einem Blinden mal?

Ich habe keine Ahnung worum es geht und es interessiert mich auch nicht.
Ich staune nur, bei wie vielen "Experten" Google kaputt ist.
https://synopse.info/files/html/Synopse ... tml#SOURCE

[wodim]

Aber unter deinen Links finde ich "Kapitel 1 Synopse mORMmot Overview" nicht. Zeigst du es einem Blinden mal?

Ich habe keine Ahnung worum es geht und es interessiert mich auch nicht.
Ich staune nur, bei wie vielen "Experten" Google kaputt ist.
https://synopse.info/files/html/Synopse ... tml#SOURCE

Danke. Ich habe auch nie behauptet, Experte zu sein. Aber wie ich die Sache sehe, ist das für meine vergleichsweise simple Anwendung doch 3 Nummern zu groß, schon der Einarbeitungsaufwand.

[wodim]

Es läuft also doch auf einen einfachen "DIY"-Server hinaus.

Also was muss mein Server denn können? Ein paar einfache Funktionen ausführen, die den Datentraffic zwischen Datenbank, Objekten in der "Mittelschicht" und Clients realisieren.

Dazu kriegt er also von den Clients Anforderungen als Strings, die er sich "decodieren" (in Funktionsaufrufe umsetzen) muss und dem Client dann Ergebnisse zurückliefern.

https://stackoverflow.com/questions/307 ... locksocket

Hm, das ist das Prinzip, wie ein Client Verbindung mit dem Server über einen TCP-Socket aufnimmt. (Ok, ich muss keinen Stream übertragen, nur einen String.) Aber wie bringe ich dem Server (möglichst genauso einfach) bei, dass er auf Anfragen von Clients "'lauschen" soll?

[af0815]

Worin liegt der Sinn, mehrere Schichten in einer Anwendung aufzubauen, also letztlich auf jedem Client?

a ) Skalierbarkeit,

Hallo, was mit 10 Datensätzen geht, geht auch mit 1 Mio Datensätzen.

Danke für die Info, jetzt mit der Aussage kenne ich deinen Zugang zu Datenbankservern. Wir brauchen in keiner Weise mehr weiterdiskutieren. Bleib im DIY Bereich.

[wodim]

a ) Skalierbarkeit,

Hallo, was mit 10 Datensätzen geht, geht auch mit 1 Mio Datensätzen.

Danke für die Info, jetzt mit der Aussage kenne ich deinen Zugang zu Datenbankservern.

Das war doch nicht ernst gemeint. (Ich werd's schon noch lerrnen, jedes Wort auf die Goldwaage zu legen.) Schon klar, dass "Skalierbarkeit" in diesem Zusammenhang was anderes bedeutet. Aber was sagt das über meinen Zugang zu Datenbankservern aus? Und darüber, wie ich den in diesem Projekt für den Admin und für jeden "normalen" User einrichten will?

Bleib im DIY Bereich.

Da will ich anfangen, weil wie gesagt so ein komplexes Framework für so eine simple Anwendung mit Kanonen auf Spatzen geschossen ist.

[wodim]

Wenn du deinen "Mittelmann" wirklich auf ner separaten Maschine laufen lassen willst, wirst du an genannten "Kommunikations-Methoden" nicht vorbeikommen.
Und siehe da, da sind ja auch schon die erwähnten Sockets und UDP

Genau.

https://wiki.freepascal.org/Networking# ... a_bit_more

Hab' mir also mal das lNet - Beispielprojekt "tcpudp" vorgenommen. Krieg's leider nicht zum Laufen.
1. In der IDE wird die Form nicht angezeigt, das Object-Inspector-Fenster bleibt leer.
2. Beim Compilieren kommt Folgendes:

Code: Alles auswählen

main.pas(234,13) Error: identifier idents no member "SocketNet"

Was stimmt da nicht? Hab's mal unten angehängt. Danke im voraus für jeden zielführenden Fehlersuchhinweis.

[wodim]

Hab' mir also mal das lNet - Beispielprojekt "tcpudp" vorgenommen. Krieg's leider nicht zum Laufen.
1. In der IDE wird die Form nicht angezeigt, das Object-Inspector-Fenster bleibt leer.
...
Was stimmt da nicht?

Das war der Fehler (in der main.lfm, Z. 195):

Code: Alles auswählen

object SSL: TLSSLSessionComponent
...
    Method = msSslTLS
...
end          

Darauf muss man erst mal kommen. Hab' eine neue Form kreiert und den Code häppchenweise übernommen, bis eben die Form nicht mehr angezeigt wurde. Mit den vorgeschlagenen Methoden "msTLS" oder "msTLSv1_2" gips das Problem nicht. Weiß der Geier, wie "msSslTLS" da 'reingeraten ist. Na, das war ja wieder mal eine Geburt. (Gem. Murphy's laws kam ich natürlich auf die fehlerhafte Zeile ganz zuletzt.)

Aber zu 2. Der Compiler meldet nach wie vor:

main.pas(42,36) Hint: Parameter "aSocket" not used
main.pas(47,53) Hint: Parameter "aSocket" not used
main.pas(48,35) Hint: Parameter "aSocket" not used
main.pas(50,39) Hint: Parameter "aSocket" not used
main.pas(234,13) Error: identifier idents no member "SocketNet"

Da bin ich wie gesagt mit meinem (Anfänger-) Latein am Ende. Wer weiß weiter? Wie immer danke im voraus.

[theo]

main.pas(234,13) Error: identifier idents no member "SocketNet"

Das kann eigentlich nur bedeuten, dass das Beispiel nicht mit deiner Version von lNet übereinstimmt.
Hier existiert es das Property "SocketNet" : https://github.com/almindor/lnet/blob/m ... ib/lnet.pp