Client - Server oder nicht

Hallo,
ich überlege mir gerade, was für konkrete Vorteile es bringt, eine Anwendung auf Client und Server aufzuteilen. Planungstechnisch einfacher und schneller geht es doch wenn man nur Client hat und nur die Datenbank auf dem Server. Durch eine AutoUpdate funktion gilt das Argument, dass Veränderungen nur an einer Stelle ausgeführt werden müssen aucht nicht wirklich. Nun würde mich interesieren wo ihr da noch Vor-/Nachteile seht.
Bin für Tipps dankbar.

Hallo daniel,

die Frage allgemein zu diskutierten führt in meinen Augen zu weit. Es gibt zu viele Gründe für die Aufteilung, genauso wie das etliche Nachteile mit sich bringt. Für welches konkrete Programm überlegst du die Aufteilung? Wenn du es wirklich allgemein wissen willst, schau bitte in ein entsprechenden Buch und vielleicht auch bei Wikipedia, bevor wir uns hier die Finger wund tippen müssen. 🙂

herbivore

Konkret handelt es sich um ein kleines Programm womit Aufträge bearbeitet werden, Kundenstamm solche dinge eben und es greifen ca 3-4 Clients auf die Daten zu.

Hallo daniel,

ich denke in diesem Fall lohnt sich Verteilung m.E. nicht. Wie du schon sagst reicht es, wenn hier die Datenbank auf dem Server liegt.

herbivore

Okay, habe ich mir auch gedacht.
Lohnt sich die Verteilen wenn es mehr Clients werden oder nichtmal dann?

Hallo daniel,

müssten vermutlich schon richtig viel mehr Clients werden, bevor sich das ünerhaupt lohnt. Also vielleicht ab 25-50. Und selbst dann ist es nicht zwangsläufig notwendig.

herbivore

Die Aufteilung in Client/Server ist eine logische. C/S braucht man z.B. dann wenn gleichzeitiger Mehrbenutzerbetrieb gewünscht ist. Dabei spielt es überhaupt keine Rolle, ob es sich um 2 opder um 50 Clients handelt. Solche Zahlen spielen erst dann eine Rolle, wenn man die genaue Ausprägung einer C/S-Architektur plant. Klassische 2-Schicht-Architekuren (Clients greifen direkt auf die DB zu) skalieren eher schlecht bis gar nicht.

Hallo,
nur weil man keine Trennung Client / Server hat ist doch nicht gleich eine 2-Schichten Architektur vorhanden. Man kann doch trotzdem UI, Datenzugriff, Businesschicht usw haben oder nicht?
Der einzigste Unterschied ist nur, dass alles auf dem User Pc läuft und nicht teilweise auf dem Server?!

Hallo daniel,

du hast Recht und svenson hat nie das Gegenteil behauptet. 🙂

herbivore

Naja, in dem Zusammenhang von 2-Schichten zu reden lässt schon darauf schließen 😜

Aber so allgemein gesehen stimmt schon, sorry!

Hi,

vielleicht wären hier die englischen Vokabeln "tier" und "layer" besser gewesen. Z.b ne 2-tier-application mit 3 Layern.

Vielleicht nochmal zu deiner Frage: "Was ist der Vorteil?"

Vorteil gibt es genau einen: Mehrbenutzerbetrieb bzw. gemeinsame Datenhaltung. Punkt. Aus.

Du hast noch Stichworte genannt wie "AutoUpdate". Ein "AutoUpdater" hat aber mit C/S aus Sicht der Anwendung gar nix zu tun, außer dass es eben eine gemeinsame Datenhaltung für Updates gibt. Du kannst genausogut eine Einzelplatzlösung mit einem AutoUpdater versehen. Der "AutoUpdater" selbst mag ein C/S-System sein, der Anwendung ist das aber Wurscht und wird damit selbst nicht automatisch zu einem C/S-System, auch wenn man das aus einer rein technischen Sicht so sehen könnte.

Hallo Generalissimo,

das wäre dann aber deine Definition der Begriffe. tier impliziert nicht, dass die Anwendung verteilt ist. tier und layer sind mehr oder weniger synonym.

herbivore

Original von Generalissimo
vielleicht wären hier die englischen Vokabeln "tier" und "layer" besser gewesen. Z.b ne 2-tier-application mit 3 Layern.

Völlig richtig. Die Frage bezog sich wohl eher auf Tiers, nicht auf Layer. Bitte meine Postings auf "Tiers" beziehen. 3 Schichten kann man ja auch in einer Standalone-Anwendung haben.

Original von herbivore
das wäre dann aber deine Definition der Begriffe. tier impliziert nicht, dass die Anwendung verteilt ist.

Und ich dachte immer, genau DAS sei die Definition von Tier. Ein Tier ist die Prozess-Sicht, während Schichten logische Code-Anordnung ist.

3-Tier-Systeme bestehen aus einer DB, einem App-Server und einem Client.

Ein Standalone-Anwendung kann aber sauber in 3 Schichten entwickelt werden.

http://www.lhotka.net/WeBlog/CommentView,guid,a70aad9c-79fd-45cc-875f-00dfd3dc0fb6.aspx

Hallo svenson,

nach http://de.wikipedia.org/wiki/Multi-Tier-Architektur ist Tier = Schicht. Und es steht da, dass die Schichten verteilt sein können.

herbivore

PS: Auch das Englische Wikipedia benutzt tier und layer synonym: http://en.wikipedia.org/wiki/Three-tier_%28computing%29

Hallo Daniel,

Client/Server lohnt sich immer, also Fat-Client und Datenbankserver (Two Tier Architektur)

Anwendungslogik in einem eigenen Prozess (Multi Tier Architektur) lohnt sich nur wenn die Verbindungen der Clients mit dem Server oder die Rechenleistung des Client zum Engpass werden kann. Also entweder bei einer sehr großen Userzahl, von denen einige z.B. über VPN angebunden sind, oder sehr grosse Applikationen, mit denen ein Client überfordert wäre.

Egal wieviele Schichten (2, 3 oder mehr), alle Schichten können auch auf einem Rechner laufen. Nur in verschiedenen Prozessen. Für 3 Tier sind also nicht 3 Rechner erforderlich.

Grüße Bernd

Original von herbivore
nach
> ist Tier = Schicht. Und es steht da, dass die Schichten verteilt sein können.

Wikipedia in Ehren aber "Es wird auch von der N-schichtigen Architektur gesprochen. Und kann vom Prinzip her beliebig weit "getrieben" werden." ... 😉

Ich kann nur sagen, dass ich dem Mann in allen Argumenten folge. Tiers und Layers gleichzusetzen, heisst zwei völlig verschiedene Dinge zu vermischen.

**Logical layers are merely a way of organizing your code. **Typical layers include Presentation, Business and Data – the same as the traditional 3-tier model. But when we’re talking about layers, we’re only talking about logical organization of code. In no way is it implied that these layers might run on different computers or in different processes on a single computer or even in a single process on a single computer. All we are doing is discussing a way of organizing a code into a set of layers defined by specific function.

Physical tiers however, are only about where the code runs. Specifically, tiers are places where layers are deployed and where layers run. In other words, tiers are the physical deployment of layers.

Why do we layer software? Primarily to gain the benefits of logical organization and grouping of like functionality. Translated to tangible outcomes, logical layers offer reuse, easier maintenance and shorter development cycles. In the final analysis, proper layering of software reduces the cost to develop and maintain an application. Layering is almost always a wonderful thing!

Why do we deploy layers onto multiple tiers? Primarily to obtain a balance between performance, scalability, fault tolerance and security. While there are various other reasons for tiers, these four are the most common. The funny thing is that it is almost impossible to get optimum levels of all four attributes – which is why it is always a trade-off between them.