Hallo Leute,

es handelt sich bei diesem Posting wohl eher um eine Frage nach
Three-Tier aber ordentlich.

Ich plane derzeit ein Projekt, wie oben im Titel zu erahnen ist handelt es sich
um eine Three-Tier-Architektur.

Nun hätte ich einmal die Bitte, ob ihr mir nicht ein paar Tips geben könnt.
Die Zugriffe auf die Datenbank sollen vom Client nur über den Server gehen.
D.h. der Client fragt beim Server an und dieser gibt die Ergebnisse zurück.
z.B.: SELECT * FROM Tabelle WHERE x like y
Das Ergebnis braucht natürlich nur der Client.

Zudem kann der Server auch andere Clientanfragen verarbeiten.
z.B.: Dateitransfer etc.

Was sind gute Lösungsansätze für diese Problematik?
Welche Komponenten bieten sich Client- und Serverseitig an (DB-Zugriffe)
um eine performante Lösung erreichen zu können?

Danke im Vorraus.

das was du schreibst, ist eine klassische Client-Server Architektur und hat nicht viel mit Three-Tier zu tun.

Du brauchst ein
1. Oberfläche und davon abgekapselt eine
2. Logik sowie die
3. physische Datenbank

schau mal hier www.dfpug.de/konf/ko...er/d_tier/d_tier.htm

grez
msch

MSCH hat folgendes geschrieben:

das was du schreibst, ist eine klassische Client-Server Architektur und hat nicht viel mit Three-Tier zu tun.

Nicht? Ich dachte immer Client <-> Server <-> Datenbank wären Three-Tier-Architekturen?

Danke für den Link im Übrigen, da ist es ähnlich beschrieben.

Aber die eigentliche Frage ist für mich eher:

Per Client auf die DB zugreifen ist kein Problem.
Ich möchte, dass der Client die SQL-Statements oder Stored Procs. an den Server weiterreicht und der von der DB die Infos holt und wieder zurück zum Client.

Ich hab da bis jetzt an soetwas wie Streams schicken und senden gedacht.
Das Ergebnis vom Server, nach der Anfrage vom Client, soll per Stream ankommen.
Die Datenmenge liegt also in diesem Moment beim Client.
Kann ich dann mit irgendeiner DB-Komoponente direkt den Stream interpretieren?
Sowas einfaches wie x.LoadFromStream( aStream );

Im Prinzip suche ich dafür eine geschmeidige Lösung:
Welche Komponenten wären z.B. sinnvoll? (Indy für Client und Server)
ADODataSet etc...

Thx

Fast das letzte Wort ist das gesuchte und es heißt "Dataset". Das ist quasi Dein "Stream". Damit schickt man seinen Wunsch an die DB und die schickt das Gewünschte dann in einer Datenmenge an das Ding zurück und fertig. Toll was ?

Also im Klartext ( und ich meine die Frage tatsächlich ernst ) bietet es sich an DataSets per Stream zum Client zu schicken?

Ich frage das deshalb, da ich versuche eine sinnvolle Lösung finden bzw. das ganze Projekt sauber gestalten möchte.

(deshalb stell ich mich auch bewußt blöd... was ist eigentlich Delphi? : )

Stelle dich aber nicht zu blöd an ! :warn: Toller Smiley. Ersetze überall in deinen Postings das Wort Stream durch Dataset und dann könnte es ein C/S Programm werden.

Langsam bin ich verwirrt.
Dir ist klar was ich mit Client <-> Server <-> Datenbank meine oder?

Ah ja. Darüber stehen hier mind. 10.000 Beiträge.

Bei den 3 Tieren ist eines zuviel. Du hast das C/S Prinzip noch nicht verstanden. Stark vereinfacht : Server (=Datenbank) und Client (=Programm). Und das Zwischenstück ist erstens, dem Server zu sagen, welche Daten man will und sofern der die hat, dann soll das Programm, also der Client, ja was damit anfangen. All das macht das DataSet.

Ich hab das Prinzip nicht verstanden.. dann erklär es mir mal genauer denn
das hier ist keine Kunst:

TADOConnection: Datenbank angeben.
TADODataSet : Connectionobjekt angeben.
TADODataSource: Connection angeben DataSource angeben.

Das in obigem Fall die DB als Server dient ist nicht gerade interessant für mich.

Für das was ich vorhabe gibt es einen Client und einen Server, wir denken uns jetzt mal die Datenbank weg.
Was bleibt ist eine stupide C/S Angelegenheit.
Ich möchte den Client also komplett von der DB abgekapselt.
Zugriff auf die DB hat also nur der Server.

Ein Beispiel für eine solche Lösung:
www.delphi3000.com/a...article_3209.asp?SK=


P.S.: Der Client soll vom Server ja nicht nur einzelne Datenmengen der DB bekommen sondern auch Messages verarbeiten könnten.

P.P.S.: Nach meinem Prinzip Server + Client + irgendeine Datenbank handelt es sich IMHO schon um eine Drei-Kamele-Anwenung. Korrigiert mich bitte, wenn ich wirklich in einem Irrglauben lebe.

P.P.S.: Hoffe, die Antwort hier wird nicht als Angriff oder so aufgefasst.

Hallo,

vielleicht redet Ihr einfach aneinander vorbei:

Die typische Client-Server-Lösung besteht im Grunde genommen aus einem Client und einem Server - wobei die Datenbank quasi mit dem Server gleichgesetzt wird.

Eine Three-Tier bzw. N-Tier Lösung bietet z.B. ASP .NET an, der Client (Browser) ruft beim IIS eine Seite auf und dieser wiederum holt sich die Daten bei einer Datenbank.

Borland hatte "früher" die MIDAS-Komponenten (zumindest in der Enterprise/Architect) mit dabei, mit denen eine N-Tier Lösung erzeugt werden konnte. Was diese aber heute noch für nen Stellenwert haben weiß ich nicht, ich denke, ASP.NET wäre da eher die richtige Wahl.


Für weitere Tipps wäre es sinnvoll zu wissen, wie Du die N-Tier Lösung implementieren willst (also z.B. kein .NET,....) und warum überhaupt ne N-Tier Lösung....

Grüße
Lemmy

N-Tier deswegen, weil:

- der Server Datensätze, die von dem einen Client benutzt werden, für den anderen Client
sperren soll.
- Nachrichten zwischen den Clients hin und her geschickt werden sollen.
- Auch Dateien direkt vom Client zum Server geladen werden sollen.
- Sauber Netzwerkfähig
- Datenverschlüsselung

Zitat:

Für weitere Tipps wäre es sinnvoll zu wissen, wie Du die N-Tier Lösung implementieren willst (also z.B. kein .NET,....) und warum überhaupt ne N-Tier Lösung....

Eigentlich hatte ich für zusätzliches Brainstorming ursprünglich diesen Thread hier eröffnet.

Ich weiß nicht wirklich, wie ich realisieren kann, dass der Client seine Abhängigkeit zur Datenbank verliert ohne, dass ich die Vorteile von z.B.: DataSet, Query, DataSource verliere.

Es wäre schön, wenn man auf Serverseite einen Stream zum Client schicken könnte und dann auf Clientseite "DataSet.LoadFromStream()" machen würde und alles ist schön.
Aber so einfach scheint es nicht.

Hi,

für die Sperrung der Datensätze (Locking) ist eigentlich der Datenbankserver verantwortlich. Jedes DBMS hat dort seine eigene Strategie. Nachrichten zwischen den Clients zu versenden ist auch kein Problem, lässt sich mittels TCP/IP Komponenten ohne Probleme lösen - mit zusätzlichem Server oder ohne. Dateien zu Server laden geht auch. Wenn die Dateien nicht in der DB gespeichert werden soll, brauchst Du nen zusätzlichen Server, der die Verwaltung übernimmt. Sauber Netzwerkfähig ist jede Client-Server-Architektur, bei deren Entwurf keine Fehler gemacht worden sind (z.B. Access oder Paradox als Datenbank). Datenverschlüsselung ist auch kein wirkliches Problem. Ich meine zu wissen (Experten bitte bestätigen oder berichtigen), dass es DBMS gibt, die den Datenverkehr verschlüsseln können.

Alles in allem lässt sich diese Appl auch ohne Three-Tier Lösung machen, weil keine Deiner Anforderungen eine Three-Tier-Architektur erfordert, es werden nur verschiedene Server benötigt (eine Datenbank, ein FTP-Server, ein Messaging-Server).

Grüße
Lemmy

[edit]
Nochmal: eine N-Tier Lösung ist dann notwendig, wenn ein Poor-Client (z.B. ein Browser) die Anwenderschnittstelle übernehmen soll. Sonst sind das technisch gesehen immer Client-Server Lösungen.
[/edit]

Zumindest bei Delphi7, vermutlich auch später, gibt es Provider-Komponenten, die das tun, was du willst. Damit kann man eine Verbindung zwischen 2 Datasets herstellen, wobei die eigentliche Kommunikation über z.B. COM oder SOAP läuft.

Die DOH bietet zu mehrschichtigen Anwendungen ein eigenes Hilfethema, wo das erstellen solcher ganz gut erklärt wird.

Das ein DBMS Locking selber vornehmen kann, wußte ich nicht.
Gut zu wissen.

Um das senden von Dateien oder Nachrichten mach ich mir ja auch keine Gedanken.
Das ist nur noch ne Fleißaufgabe.

Weil du von Poor-Clients gesprochen hast.
Einen Fat-Client habe ich schoneinmal entwickelt, also klassisch Client + Datenbankserver.

Mir geht es eigentlich darum zu erfahren wie ich eine solche Technologie (n-Tier) am besten bzw. überhaupt umsetzten kann.

Ich hab selber schon geschmökert und sowas gefunden:
MIDAS, RemObjects etc...

Die meisten Lösungen sind kostenpflichtig und fallen somit für mich weg.

Ich hab sowas auch mal angefangen. Sicher war es bei mir nicht die optimale Lösung, recht aufwändig, aber es hat funktioniert.

Im Hintergrund lief eine mySQL-Datenbank. Auf diese griff der Server per ZEOS-Komponenten zu. Der Server stellte einen TCP-Server (Indy 9) zur Verfügung zu dem sich die Clients verbinden konnten. Der komplette Datenaustausch zwischen Client und Server fand in XML statt, ich habe also ein kleines XML-basiertes Protokoll dafür entwickelt.

Das ist dann natürlich sehr viel Handarbeit.

Inwiefern sind heute solche Architekturen noch notwendig?
Früher- mit "dummen" Terminals und schmaler Hardware hat sich das vielleicht gelohnt auf 3 oder mehr schichten auszuweichen. (Dünner Client - dicke Serverhardware)
Ich kann mir nur einen Sinn vorstellen; Client im Internet - Vermittler in der DMZ - Datenbank im Unternehmen. Das
Ganze via SOAP oder WDSL oder wie auch immer. Also dann, wenn irgentwelche Einschränken einen direkten Zugriff auf die DB nicht erlauben (Firewall etx).

Ich würd sagen, schraub ne Anwendung die auf eine SQL-DB zugreift (klassische C/S) und belasse soviel wie möglich
an Logik in der Datenbank. Erstens wird die Applikation schlank und die Datenbankserver sind meistens so dimensioniert,
dass die eh nur im Leerlauf rumgammeln. Da bedeutet, viele Views und Stored Procs etc. Der Vorteil, die Änderung an der Logik erfolgt an zentraler Stelle - dort wo die Daten liegen - und nicht beim Client. Hat Wartungsvorteile und du musst nicht jedem Anwender eine neue Softwareversion geben.


grez
msch

Es gibt schon noch Einsatzgebiete, wo das Modell sehr viel Sinn macht. Ein Einsatzgebiet ist zum Beispiel ein Portalsystem, die Server stehen bei dem Portalanbieter, die Clients laufen bei den Nutzern. Da kann man dann entweder auf sowas wie Citrix setzen, oder man setzt eine 3-Schicht-Architektur ein ( wenn ich ein Webportal mit PHP baue, is das ja auch schon 3-Schichtig mit dem Broser als Client ).

Wenn Server und Clients innerhalb des selben Netzwerks beheimatet sind, ist der Nutzen sicherlich fraglich.

Hi,

nein, denn auch innerhalb eines Netzes macht ein solcher Aufbau Sinn, wenn z.B. der IIS, MS SQl-Server und IE ein Firmenweites Intranet mit CRM,.... aufbaut. Die Entwickler müssen auf keinem Client irgendwass installieren oder updaten sondern können direkt am Server die Neuentwicklungen einspielen. Zu was sonst gibts wohl die ASP .NET Geschichten...??

Grüße
Lemmy

Ich sagte ja nicht gänzlich unsinnig, sonder der Nutzen ist fraglich. Eine solche Architektur bringt immer zusätzliche Fehlerquellen und Performanceeinbußen mit sich, die aber durchaus so marginal sein können, dass sie nicht ins Gewicht fallen.

Hi,

ich wollte eigentlich nicht über Sinn und Unsinn von solchen Systemen diskutieren (zumindest nicht primär, obwohl es auch wichtig ist).

Ich wollte ein paar Tips von euch, welche Technologien für eine Three- bzw. N-Tier-Architektur verwendet werden können/ sollten.

Also Hinweise zu sowas, was hier schon vorgeschlagen wurde.

Zitat:

SOAP, WSDL, ASP.Net

Auch würde mich interessieren, was man bei der Planung beachten sollte.
Also aus eurem profunden Wissensschatz schöpfen.

Meine Erfahrung von Two-Tier-Architekturen mit Dokumentenverwaltung, Nachrichtensystemen und was sonst noch dazu gehört, habe ich schon gesammelt.
Mit solchen Systemen habe ich nicht so das Problem. (kommt aber auch auf die Dimensionierung an)

Danke