Diskussion:Schichtenarchitektur

(mutmaßlich, da ohne Unterschrift) Erste Anmerkungen

"Abhängigkeitsgraph" wird mit "ph" geschrieben. Die Abhängigkeiten werden ja nicht geadelt. Neue Rechtschreibung hin, neue Rechtschreibung her. Die entsprechenden Fachbegriffe (Graph etc.) sind auch in der Wikipedia entsprechend geschrieben.

---

Sollte der Begriff "Komponente" nicht besser differenziert werden. Nach Helmut Balzerts "Lehrbuch der Software-Technik" kann eine Schicht viele Komponenten enthalten und wird nicht selber als Komponente gesehen.

Verschiedene Arten von Schichtenarchitekturen sollten aufgezeigt werden (linear, strikt, baumartig).

Das Bild zeigt links eine strikte Ordnung und in der Mitte eine lineare Ordnung. Die Beschriftung ist also falsch.

---

"Komponente" ist ein sehr allgemeiner Begriff, wir können uns auf Architekturkomponente einigen. Gegenvorschläge? Kann Balzert hier wirklich als Referenz dienen? Ich persönlich halte die Anordnung der Schichten über das Abstraktionsniveau für sehr problematisch: Ist die Webschicht abstrakter oder konkreter als die zugehörige Datenschicht? Wovon abstrahiert denn eine Schicht bitte? Gibt es Schichtenarchitekturen, die der Balzertschen Definition zufolge "nicht strikt" wären? Würde man dann noch von Schichtenarchitektur sprechen? Nun bin ich mit den Begriffen "linear" oder "strikt" ein wenig ratlos. Gibt es noch andere Referenzen, nicht gerade Balzert?

Zusammenlegung von Schichtenarchitektur, Mehrschichtige Architektur und Zweischichtige Architektur

Alle 3 Artikel beschäftigen sich derzeit mit dem gleichen: Mehrschichtige Architekturen. Zusammengenommen würden sie einen guten Artikel ergeben, einzeln sind sie nicht besonders wertvoll. Ausserdem ist die Aufgliederung sehr fraglich (alle Schichtenarchitekturen sind Mehrschichtige Architekturen, auch eine Zweischichtige Architektur ist eine Mehrschichtige Architektur). Wenn kein Einwand kommt, dann übernehm ich gerne das Zusammenlegen... --Sebastian.Dietrich 12:33, 21. Jan. 2007 (CET)

---

Jipp, finde ich eine gute Idee. Ich habe diesen Artikel hier eigentlich nur eingestellt, weil ich die anderen nicht gefunden habe. Vielleicht kann man dabei auch gleich ein paar Fehler korrigieren und Literaturverweise einstellen.

Ich habe die verschiedene Architekturmodelle in diesem Artikel zusammengefasst. Application Server sollte als eigenständiger Artikel bestehen bleiben... dieser Artikel sollte inhaltlich aber gerne nochmal überarbeitet und ergänzt werden! RIMOLA 17:39, 10. Feb. 2008 (CET)

unter 5-schichtige kommt noch einmal eine Einleitung, die da wohl nicht mehr hingehört?--141.3.167.88 20:37, 28. Apr. 2008 (CEST)

Ist somit erledigt - danke Rimola --Sebastian.Dietrich 18:41, 16. Aug. 2009 (CEST)

Schichten überspringen

Sind die folgenden Sätze aus dem Artikel korrekt?

„Bei einer linearen Schichtenarchitektur dürfen dabei keine Schichten übersprungen werden. Liegt hingegen eine Schichtenarchitektur mit strikter Ordnung zugrunde ist es möglich einzelne Schichten zu überspringen.“

In der Grafik ist ein Überspringen einzelner Schichten in einer strikten Schichtenarchitektur nicht möglich. Was stimmt denn nun? Und was ist dann eine lineare Schichtenarchitektur? --83.135.187.160 00:47, 1. Mär. 2008 (CET)

Ist inzwischen korrigiert (strikt war falschherum beschrieben) --Sebastian.Dietrich 16:50, 16. Aug. 2009 (CEST)

Differenzierung Schichten (Layers) und Tiers

Hallo alle, im Unterricht lernen wir eine Differenzierung zwischen Schichten (Layers) und Tiers. Tiers sind dabei physikalisch verteilbare Schichten (-> verteilte Systeme). Dies ist auch sonst weit verbreitet, siehe: http://www.google.ch/search?hl=de&q=layer+tier&meta= Wäre diese Unterscheidung auch angebracht? Ich würde vorschlagen, dass man allg. von Schichten redet und die Tiers als "physikalisch verteilbare Schichten" beschreiben würde [mit physikalisch verteilbar ist Verteilung auf mehrere Hosts gemeint]. Hansen unterscheidet Schichten (Layers) von Stufen (Tiers):

• Hansen / Neumann, "Wirtschaftsinformatik, Band 2" ISBN 978-3825226701 , Seite 768 ff.

Für diese Klarstellung wäre ich absolut dankbar! In dem aktuellen Artikel wird beides so wild durcheinander geworfen, dass man sich fragen muss, wozu es überhaupt diese beiden Begriffe gibt. - Allerdings wird auch im englischen Artikel keineswegs unterschieden, wenn auch viele Autoren außerhalb Wikipedia sehr dafür plädieren.

Sehe ich genauso. Hier wird das Thema auch gut behandelt: http://blogs.msdn.com/diegumzone/archive/2006/10/09/3_2D00_Tier_2C00_-3_2D00_Layer_2C00_-MVC_3A00_-a-Trio-of-Famous-Trios.aspx -- 84.133.249.119 15:17, 27. Jan. 2010 (CET)

Kann dem uneingeschränkt zustimmen. Der Artikel hat in seiner jetzigen Form für mich sehr schlechte Qualität und eignet sich IMHO nicht zur Klärung der Begriffe --213.179.148.2 16:17, 11. Okt. 2012 (CEST)

Unterstützung! --91.114.200.194 16:22, 2. Mai 2013 (CEST)

Sei mutig und ändere den Artikel... --Sebastian.Dietrich ✉ 17:16, 2. Mai 2013 (CEST)

{{Überarbeiten}}

Ich habe die Einleitung überarbeitet und den Artikel etwas gegliedert. Aber insgesamt ist es immer noch eine wilde Mischung aus einigen zusammengelegten Originalartikeln mit vielen Dopplungen und ohne klare Struktur. Vielleicht komme ich dazu, dass demnächst in Angriff zu nehmen, aber wenn jemand anderes schneller ist, habe ich auch nichts dagegen. -- S.K. 06:03, 9. Mai 2008 (CEST)

Sei mutig! Bin schon gespannt, was aus dem Artikel noch werden kann. --RokerHRO 09:35, 9. Mai 2008 (CEST)

Nachteile fehlen

Für einen objektiven Artikel fehlen noch die Nachteile. Zweifelslos hat jede Architektur ihre Vorteile, aber ebenso auch Nachteile. Erst durch die Nennung dieser kann eine gewisse Neutralität gewahrt werden, die dem Leser die größtmögliche Entscheidungsfreiheit lässt.

Bildbeschreibung fehlt bei [[Bild:tier-aufteilung.jpg|thumb]] und [[Bild:Schichtenmodell.jpg|thumb|right]]

Der Artikel enthält ein Bild, dem eine Bildbeschreibung fehlt, überprüfe bitte, ob es sinnvoll ist, diese zu ergänzen. Gerade für blinde Benutzer ist diese Information sehr wichtig. Wenn du dich auskennst, dann statte bitte das Bild mit einer aussagekräftigen Bildbeschreibung aus. Suche dazu nach der Textstelle [[Bild:tier-aufteilung.jpg|thumb]] und [[Bild:Schichtenmodell.jpg|thumb|right]] und ergänze sie.

Wenn du eine fehlende Bildbeschreibung ergänzen willst, kannst du im Zuge der Bearbeitung folgende Punkte prüfen:

• Namensraum Datei: Bilder sollte im Namensraum Datei liegen. Bitte ändere die alten Bezeichnungen Bild: und Image: in Datei:.
• Skalierung: Außerhalb von Infoboxen sollten keine festen Bildbreiten (zum Beispiel 100px) verwendet werden. Für den Fließtext im Artikelnamensraum gibt es Thumbnails in Verbindung mit der automatischen Skalierung. Um ein Bild/eine Grafik in besonderen Fällen dennoch größer oder kleiner darzustellen, kann der „upright“-Parameter verwendet werden. Damit erfolgt eine prozentuale Skalierung, die sich an den Benutzereinstellungen orientiert. --SpBot 10:12, 2. Mär. 2009 (CET)

Bilder falsch bzw. verwirrend

Die Bilder "Beispiel einer 3-Schichten-Architektur", "Erweiterung einer Drei-Schichten-Architektur um Präsentations-Schicht" und "Erweiterung Daten-Integrations-Schicht" sind nicht richtig bzw. unklar. Im Text stehen die richtigen Schichten: Präsentationsschicht, Logikschicht bzw. Anwendungsschicht und Datenhaltungsschicht. Die Bilder hingegen zeigen: Anwendungsschicht, Domänenschicht und Datenschicht.

Die Anwendungsschicht im Sinne von "Application Layer" bzw. "Service Layer" befindet sich zusammen mit der Domänenschicht ("Domain Layer") meist im gleichen Tier. Die Anwendungslogik ("Business Logic") liegt bei dieser Trennung Service Layer/Domain Layer definitiv in der Domänenschicht. Darüber hinaus kann eine Präsentationsschicht ("Presentation-Tier") existieren, die nicht mit der GUI verwechselt werden sollte. Die Präsentationsschicht kann dabei unabhängig vom Darstellungsmedium (Web, Desktop, Mobile) implementiert werden. Der Presentation-Tier befindet sich z.B. bei einer Web-Anwendung in den meisten Fällen auf dem Web-Server und nicht im Browser des Nutzers. Die konkrete GUI ("User Interface Layer") nutzt die Präsentationsschicht für die Aufbereitung der Daten. Z.B. in einer Web-Anwendung wird das HTML auf dem Server erzeugt (Eingaben des Nutzers werden verarbeitet) und im Browser angezeigt. Ganz konkret: Eine englische/kryptische Fehlermeldung aus der Anwendungsschicht wird in der Präsentationsschicht übersetzt und nicht erst in der GUI.

Löschung des Absatzes "Nachteil"

Hallo ʘx, deine Aussage, Dass in einem Layer nur Delegation stattfindet, ist eben kein Nachteil, sondern genau die Idee., ist m.E. nicht haltbar, sorry. Stell dir folgende Situation vor: Die Architekturvorgaben fordern striktes Layering und die Architektur sieht z.B. Client-, Process-, Business- und Persistenzlayer vor. Fachlich sind in einem Client an einer Stelle nur elementare CRUD-Operation notwendig. Dann sind die durch die Layeringregeln notwendigen Delegationen, die im Process- und Businesslayer stattfinden, aus fachlicher Sicht erst einmal reiner Overhead. Um solche Situationen zu umgehen verwendet man ja oftmals loose layering. Je nach Kontext muss man dann entscheiden, was wichtiger ist: geringere Kopplung oder weniger Code/Call-Overhead. Aber den Absatz zu löschen, der sagt, dass (insbesondere striktes) Layering ein Nachteil sein kann, ist nicht gerechtfertigt. Wenn Du denkst, dass wird im Absatz nicht deutlich genug, dann freue ich mich auf deinen Präzisierungsvorschlag. Im Original war es schon mal m.E. deutlicher formuliert, die Änderung des Absatzes hat den Hinweis auf das strikte Layering gelöscht, dafür aber keine Erklärung gegeben. Von daher würde ich das bei Bedarf wieder einfügen. Danke und Gruss, --S.K. (Diskussion) 01:54, 14. Sep. 2012 (CEST) PS: Die Aussage Ich will hier keinen Editwar, weitere Disk. dann falls nötig auf der Disk.seite. beim zurücksetzen, finde ich nicht glücklich. Warum eröffnest Du dann die Diskussion nicht gleich selber hier?

• Na ja, ich halte diese Form der Performanzüberlegung für einen Kardinalfehler in der Softwaretechnik. Wenn man nämlich eine Anwendung baut, die dermaßen extreme Performanzanforderungen hat, dass zwei oder drei Methodenaufrufe mehr bereits als inakzeptabler Overhead diskutiert werden müssen, dann hat man es mit einer Echtzeitanwendung zu tun, und dann muss man sowieso die komplette Architektur darauf ausrichten.
• Von Echtzeitanwendungen abgesehen jedoch behaupte ich zu wissen, dass ein "Kompromiss" zwischen geringer Kopplung und geringerem Overhead nur kurzfristig zu einem Erfolg verhilft. Mittel- und erst recht langfristig wird sich dieser Kompromiss in höherem Wartungsaufwand, mehr Fehlern und damit auch höheren Kosten äußeren. Wer vom richtigen Weg abweicht, und sei es auch nur ein wenig, kommt woanders an als beim Ziel.
• Dieser "Extracode", den man nur zur Delegation schreibt, ist (außer bei Echtzeitanwendungen) kein Overhead, sondern Teil des zu lösenden Problems. Weil das oft nicht gesehen und behauptet wird, man müsse sich mit Sachen aufhalten, die "fachlich" mit der Aufgabe nichts zu tun hätten, wird mindestens ebenso oft schlechte Software geschrieben!
• Ok, zurück zum Artikel. Da halte ich es jedenfalls für unangemessen, ganz allgemein von "Nachteilen" zu sprechen, denn das fördert die eben von mir beschriebene Problematik. Man sollte lieber einfach darauf hinweisen, dass die Schichtenarchitektur bei Anwendungen mit Echtzeitanforderungen problematisch sein kann. ʘχ (Diskussion) 11:12, 14. Sep. 2012 (CEST) (PS: Ich habe den von dir zitierten Kommentar zu meinem Edit geschrieben, weil ich dachte, einmal könnte ich es ja noch versuchen.)

Möchte ʘχ beistimmen. Architektur ist zunächst immer mal beschwerlich. Kurzfristig gedacht ist eine "jeder darf von überall alles aufrufen" (= Big Ball of Mud) Architektur diejenige mit dem wenigsten Overhead. Ideal wäre es auch, wenn man in der Gebäudearchitektur vom 3ten Stock durch eine Türe direkt auf den Gehsteig gelangen könnte. In der Praxis ist aber eine derartige Architektur tödlich. Weniger zu dürfen ist in diesem Fall also ein Vorteil und kein Nachteil. --Sebastian.Dietrich ✉ 14:40, 14. Sep. 2012 (CEST)

Hallo ʘχ und Sebastian,

Standardaussagen zu den ersten Punkten sind “premature optimization is the root of all evil” (Donald Knuth: Zitiert nach en:Program optimization) und “The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” (Michael A. Jackson: Zitiert nach en:Program optimization). :-) Klar, das gilt prinzipiell.

Aber die "Herleitung", dass sich die Frage nur für Echtzeitsysteme stellt, geht von einem sehr einfachen Modell aus, wie die Software implementiert ist. In realen (Enterprise)-Systemen, sind die Layer häufig/meistens nicht nur triviale Methodenaufrufe sondern komplexere Konstrukte wie Komponenten (z.B. EJBs, (D)COM-Komponenten, ...), die neben der Fachlichkeit viele Cross-Cutting-Concerns wie Transaktionen, Verteilung, Logging, ... mitbehandeln. Oder das Process-Layer ist mit Hilfe von Middleware wie einem ESB implementiert. In solchen Situationen verursacht ein Layer ohne fachliche Funktionalität eben einen nicht zu vernachlässigenden Overhead. Dann kann es sehr wohl sinnvoll sein, zumindest für einen Teil der Anwendung (z.B. reine Admin-Funktionalität, die nur von internen Nutzern verwendet wird) weniger strenge Layering-Regeln zu fordern. Und das heisst NICHT, dass es keine Layering-Regeln gibt. Der zentrale Aspekt von Layering, die Gerichtetheit von Abhängigkeiten von oben nach unten, bleibt auch bei loose layering erhalten, es ist eben kein Big Ball of Mud.

Solche Überlegung anzustellen ist auch kein Plädoyer für keine Architektur sondern ist zentrale Aufgabe von Softwarearchitekten. Die Architektur eines Systems ergibt sich immer aus der Abwägung unterschiedlicher, oft wiedersprüchlicher Aspekte. :-)

Von daher bin ich weiterhin für Vorschläge dankbar, wenn ihr denkt, gewisse Punkte sollten klarer im Artikel herausgearbeitet werden.

Danke und Gruss, --S.K. (Diskussion) 20:02, 18. Sep. 2012 (CEST)

Nun, im Artikel sollte man vielleicht näher ausführen, z.B. anhand deiner obigen Erklärungen, wann genau die Schichtenarchitektur ein Nachteil sein kann, damit man sich keine falschen Vorstellungen macht. Denn der allgemeine Satz, dass da Overhead eingeführt wird, kann missverstanden werden. ʘχ (Diskussion) 22:09, 18. Sep. 2012 (CEST)

Wichtig wäre mir, dass nicht Overhead (im Sinne von Mehraufwand bei der Programmierung), sondern wenn dann nur Performance (im Sinne von Geschwindigkeit der Abarbeitung) erwähnt wird. Features umzusetzen (und Schichtenarchitektur ist, wenn richtig eingesetzt eine Lösung für eine Aufgabenstellung wie z.B. Modularisierung und somit Wartbarkeit) benötigen ja immer Mehraufwand.

Ein mMn besseres Beispiel als die Admin-Funktionalität ist denke ich Reporting. Reports greifen meist unter Umgehung des Business- und Data-Access-Layers direkt via SQL-Queries auf die DB zu. Es macht ja keinen Sinn potentiell 1.000e Business Objekte in den Speicher zu laden, nur um in einem Pie Chart irgendwelche Verteilungen darzustellen. --Sebastian.Dietrich ✉ 12:43, 19. Sep. 2012 (CEST)

So, jetzt habe ich endlich Zeit gefunden, dass mal zu ergänzen. Hoffe, es ist jetzt verständlicher. Feedback sehr willkommen.

Bezüglich Overhead ist Performance ein Aspekt, aber auch Mehraufwand bei der Programmierung kann ein Grund sein. Z.B. ein ESB wird gerne eingesetzt um nicht-funktionale Anforderungen wie gutes Monitoring oder gute Änderbarkeit zu erfüllen. Wenn diese NFAs in einem Teilbereich der Anwendung nicht gefordert werden und man generell die Wirtschaftlichkeit begründen muss, dann kann es schon sein, dass es nicht gerechfertigt ist, dort den entsprechenden Aufwand zu treiben.

Danke und Gruss, --S.K. (Diskussion) 07:49, 1. Okt. 2012 (CEST)

Das Beispiel ESB passt mMn gar nicht. ESB ist ja nur eine Möglichkeit für Kommunikation zwischen unterschiedlichen Applikationen (oder auch Schichten) und hat mit Schichtenarchitektur per se nichts zu tun. Komponentenmodell passt mMn noch viel weniger, da die weitere Untergliederung einer Schicht (in z.B. Komponenten) gar nix mit dem hier geschriebenen "Nachteil" zu tun hat. Ich hab jetzt diesen Satz gegen mein Beispiel von oben ausgetauscht. --Sebastian.Dietrich ✉ 08:27, 1. Okt. 2012 (CEST)

Das ein ESB oder ein Komponentenmodell zwingender Teil einer Schichtenarchitektur seien, stand da ja auch gar nicht („Je nachdem wie Funktionalität in einer Schicht implementiert ist (z. B. mit einem Komponentenmodell oder einem Enterprise Service Bus)“). Es sind beides Beispiele dafür WIE die Funktionalität einer Schicht implementiert sein kann:

• Ein ESB kann für die Implementation einer Schicht verwendet werden (konkret z.B. für ein Process-/Orchestrationlayer). Und wenn er dafür verwendet wird, muss man sich überlegen, ob man seinen Einsatz zwischen Client- und Businesslayer immer fordert.
• Wenn Du dir das Bild am Anfang des Artikels anschaust, dann stell dir vor, dass jede der Komponenten entsprechend einem Komponentenmodell (wie z.B. EJB) implementiert werden muss (Architekturvorgabe). Dann ist die Delegation über das Layer hinweg eben nicht nur ein trivialer Funktionsaufruf. Strikte Layeringregeln verursachen dann einen möglicherweise nicht zu vernachlässigenden Overhead.

Die beiden Beispiele sollten nur zeigen, dass die Art und Weise, wie die Funktionalität in einem Layer implementiert wird, eine direkte Korrelation mit dem (möglichen) Nachteil hat. Das nicht zu beachten war ja gerade die vereinfachende Annahme von ʘχ.

Dein Reports-Beispiel passt auch nur begrenzt. Wenn der OR-Mapper gleich aggregierte Daten aus der DB holt, dann kann man das ohne Probleme mit einer Schichtenarchitektur verbinden. Und in grösseren Systemen werden Reports oft entweder direkt im DWH implementiert oder mit dediziert Sofware wie z.B. Business Objects entkoppelt von der "normalen" Businessfunktionalität erstellt.

Gruss, --S.K. (Diskussion) 20:16, 1. Okt. 2012 (CEST)

@OR-Mapper. Klar werden die Reports üblicherweise im DWH oder mit dedizierter Software abgebildet - das ist eben genau der Bruch der Schichtenarchitektur, da es ja jetzt eine Schichtenarchitektur mit Ausnahmen ist. Ändere ich jetzt z.B. die DB-Struktur, so muss ich an 2 Stellen weitere Änderungen machen - genau sowas möchte eine Schichtenarchitektur verhindern, da es über kurz oder lang dazu führt, dass ich die DB-Struktur nicht mehr ändern kann. --Sebastian.Dietrich ✉ 20:31, 1. Okt. 2012 (CEST)

@Bruch der Schichtenarchitektur: Die Implementierung der Reports in einem dedizierten System ist doch kein Bruch der Schichtenarchitektur. Üblicherweise erfolgt das Reporting ja gar nicht auf dem gleichen Datenbestand auf den das transaktionale operative System zugreift. Dazwischen sitzt ein ETL-Tool das die Datenstrukturen dann auch noch komplett umstellt von einem relationen Modell auf ein für das Reporting optimiertes (Star- oder Snowflake-Schema). Mit dem Reporting bin ich also gar nicht mehr im operativen System und seiner Schichtenarchitektur.

@Änderungen an 2 Stellen: Redundanzfreiheit ist per se kein Ziel der Schichtenarchitektur, dort geht es primär um die Beschränkung der Abhängigkeitsbeziehungen.

Aber du bist in deiner Antwort gar nicht auf den zentralen Aspekt eingegangen: Die Aussage um die es geht, ist ja, dass die aufgrund der Layerringregeln erzwungene Delegation ein Nachteil sein kann, wenn die Delegation aufwändig ist. Aufwändig kann sie eben wegen der genannten Beispiele sein, aber es gibt natürlich noch mehr. Z.B. wenn die Architekturvorgabe ist, das ein Layer nach oben eigene DTOs verwenden muss. Dann muss im Rahmen der Delegation eine Modelltransformation erfolgen. Etc., etc.. Und diesen Aspekt vermittelt deine Version m.E. nicht deutlich genug.

Gruss,--S.K. (Diskussion) 07:53, 2. Okt. 2012 (CEST)

@Schuldige Antwort :-) Ich sehe das anders: Layeringregeln können (wie alle Architektur- und Designvorgaben) zu mehr Code/Schreibaufwand führen. Das heisst aber nicht, dass diese Regeln dann ein Nachteil sind, sondern nur dass die Umsetzung der Regeln potentiell aufwändig ist. Wenn ich z.B. auf Schichtengrenzen transformieren muss, so kann das zwar aufwändig sein, ist aber notwendig um das Ziel (nämlich dass die Modelle in unterschiedlichen Schichten unterschiedliche Strukturen haben können) zu erreichen.

d.h. die Nachteile der Schichtenarchitektur können mMn niemals "mehr Schreibaufwand" sein, da das eine notwendige Tätigkeit für die Erreichung der Schichtenarchitektur ist. Der Nachteil eines Architekten ist ja auch nicht, dass er Zeit/Geld kostet. Wenn dann müssen Nachteile der Schichtenarchitektur solche sein, die "auf Grund der Schichtenarchitektur" und nicht "zur Erreichung der Schichtenarchitektur" entstehen. --Sebastian.Dietrich ✉ 08:50, 2. Okt. 2012 (CEST)

Da stimme ich nur zum Teil zu... Das architektonische Regeln (initialen) Mehraufwand erzeugen können und dass das per se kein Nachteil ist, sehe ich genauso. Aber eines der zentralen Versprechen von Architektur sind längerfristige Vorteile (bessere Änderbarkeit, Skalierbarkeit, Portierbarkeit, ...). Von daher sind architektonische Regeln/Vorgaben kein Selbstzweck, sie müssen sich einer Güterabwägung/Kosten-Nutzen-Betrachtung stellen wie fachliche Anforderungen auch. Von daher können (strikte) Layeringregeln in einem gewissen Kontext sehr wohl ein Nachteil sein oder anders gesagt: sie sind aus einer Gesamtbetrachtung heraus nicht zu rechtfertigen. Beispiel: Eine Wegwerf-Einmal-Anwendung für z.B. eine Migration hat andere architektonische Anforderungen als eine, an der 100 Entwickler über 10+ Jahre gearbeitet haben und weitere 10+ Jahre arbeiten werden. So etwas nicht zu beachten wäre eher Dogmatismus als Architektur.

Der Mehraufwand ensteht dann "auf Grund der (nicht adäquaten/zu strengen) Schichtenarchitektur", er ist für mich daher ein Nachteil der Schichtenarchitektur. Wobei das natürlich kein Nachteil von Schichtenarchitektur(en) an sich ist, sondern von einer spezifischen Inkarnation/Instanz davon in Bezug auf die restlichen Rahmenbedingungen in dem konkreten Fall.

Gruss, --S.K. (Diskussion) 20:07, 3. Okt. 2012 (CEST)

• Ja, soetwas wollte ich sagen mit "der Extracode ist kein Overhead, sondern Teil des zu lösenden Problems".
• Sicherlich ist mir aber bewusst, dass aus Sicht der Geschäftsleitung ein Softwarearchitekt ein "Nachteil" ist, weil es ja -- so die Denke des Chefs -- "im Prinzip" auch ohne den Architekten möglich wäre, den Code fertigzustellen, und ohne aufwändige Architektur könnte die Time-to-market kürzer sein. So kurz angebunden und ohne Sachkenntnis denken die ja häufig. Das bedeutet, ich betrachte die Denkweise in "Nachteilen" als sachfremd, weil es sich nicht um Nachteile handelt, sondern notwendige Arbeiten. Diese notwendigen Arbeiten erscheinen nur dann als Nachteile, wenn man keine Ahnung hat. Das ist so, als ob ein Bauunternehmer sagen würde "Warum baut ihr ein Fundament? Das ist ein Nachteil, ich will doch einen Wolkenkratzer und keinen Keller!"
• @S.K.: Ich frage mich folgendes: Du sagst, es kann sein, dass man eine Architekturvorgabe hat, bei der man bestimmte Layers einbauen muss, die für einen enormen Delegationsoverhead sorgen. Also einen signifikanten, spürbaren Overhead, was bei modernen CPU-Frequenzen jenseits der 2 GHz schon bedeutet, dass da sehr, sehr viel passiert. Ich muss mich nun fragen, ob das dann überhaupt noch eine softwaretechnisch korrekte Architekturvorgabe ist, denn man verletzt auf diese Weise ja ein wesentliches Softwarequalitätskriterium in einem außerordentlichen Maß (ein bisschen wäre ja ok), nämlich die Effizienz. Bitte versteht mich nicht falsch -- es ist ja durchaus richtig und notwendig, Abstriche bei der Effizienz zu machen, um eine ordentliche Architektur zu erreichen, da bin ich auf jeden Fall der erste, der das fordert. Aber eine Architektur, die einen dermaßen großen Overhead mit sich bringt, ist doch wohl kaum noch "ordentlich" zu nennen. Das hört sich eher danach an, als ob große, schwergewichtige Komponenten zu einem riesigen Dinosaurier von Anwendung zusammengepackt werden, der sich kaum noch bewegen kann und trotzdem noch Unmengen an Futter verschlingt. Ist das etwa gutes Softwareengineering? ʘχ (Diskussion) 12:28, 2. Okt. 2012 (CEST) (Edit: ʘχ (Diskussion) 12:31, 2. Okt. 2012 (CEST))

@Architekt als Nachteil: So kurzfristig denken zwar manche Manager/Chefs, aber nach meiner Erfahrung bei weitem nicht alle. Und dann ist es Teil der Aufgabe eines Architekten seinen/ihren Mehrwert aufzuzeigen. ;-)

@Denken in Nachteilen ist sachfremd: Da muss ich ganz heftig wiedersprechen. Gerade die Abwägung verschiedenster Treiber und die Beachtung ihrer Vor- und Nachteile ist für mich Kernaufgabe eines Architekten. Architektur ist kein Selbstzweck, auch wenn manche Vertreter der Elfenbeinturmfraktion gerne diesen Eindruck vermitteln.

@Delegationsoverhead/Effizienz: Effizienz/Performanz ist nur eine von mehreren NFAs/Qualitätskriterien. Z.B. ein ESB ist relativ effizient, aber verbraucht massiv mehr CPU-Zyklen als ein Aufruf einer einfachen Komponente oder gar ein simpler Funktionsaufruf. Trotzdem kann er im Hinblick auf die gesamten Anforderungen in Hinblick auf z.B. Änderbarkeit; Monitoring; Abstraktionsniveau, auf dem man mit dem Fachbereich diskutieren kann; ... in Summe die bessere Wahl sein. Das hat nichts mit Dinosauriern zu tun, sondern wieder einmal mit Abwägung. :-)

Gruss, --S.K. (Diskussion) 20:07, 3. Okt. 2012 (CEST)

@Denken in Nachteilen ist sachfremd: Da muss ich ganz heftig wiedersprechen. Gerade die Abwägung verschiedenster Treiber und die Beachtung ihrer Vor- und Nachteile ist für mich Kernaufgabe eines Architekten. Ja klar muss man abwägen -- ich meinte lediglich, dass das Bauen eines Fundaments kein Nachteil ist, und wer das denkt, denkt falsch.

Architektur ist kein Selbstzweck, auch wenn manche Vertreter der Elfenbeinturmfraktion gerne diesen Eindruck vermitteln. Da muss ich heftig widersprechen -- ich habe nicht die Erfahrung gemacht, dass die Elfenbeinfraktion (du meinst vermutlich entsprechende Professoren) diesen Eindruck vermitteln. Im Gegenteil -- wann immer es in meinem Studium um Architektur ging, begründeten sie immer mit Argumenten, die jeden BWLer eigentlich freuen sollten. ʘχ (Diskussion) 20:21, 3. Okt. 2012 (CEST)

Mit Elfenbeinturm meint er die Systemarchitekten, die Sofwarearchitekturen für viele Unternehmensapplikationen vorgeben, sich aber die Hände nicht dreckig machen bei der Umsetzung dieser Architekturen. --Sebastian.Dietrich ✉ 21:31, 3. Okt. 2012 (CEST)

Ja, genau. Und am besten sind die, die selber nie richtig Software entwickelt haben... :-( --S.K. (Diskussion) 07:15, 4. Okt. 2012 (CEST)

Rückrück Also ich denke wir können uns darauf einigen, dass eine für die jeweilige Aufgabe schlecht passende Architektur ein schlechteres Vor-Nachteilsverhältnis hat, als eine dafür gut passende Architektur. Und Schichtenarchitektur ist nicht immer oder sogar nur manchmal die für eine Aufgabe am besten passende Architektur. Dasselbe gilt für Architekturvorgaben wie Einsatz von ESB, EJB, Web-Services etc. --Sebastian.Dietrich ✉ 21:31, 3. Okt. 2012 (CEST)

Soweit kann ich das klar unterschreiben. :-) Zusätzlich können wir glaube ich festhalten, dass es auch bei Vorhandensein und grundsätzlicher Sinnhaftigkeit einer Schichtenarchitekur es Ausprägungen davon geben kann, die für den Kontext besser oder weniger gut passen, okay?

Wenn ja, wie können wir das Ergebnis unser Diskusison in den Abschnitt Vor-/Nachteile einbauen? --S.K. (Diskussion) 07:15, 4. Okt. 2012 (CEST)

Falsche Vergleiche

Hier werden einfach Äpfel und Birnen verglichen. Das (leider oft unrealistische) OSI-Modell hat nun rein gar nichts mit der Serverarchitektur zu tun. Es beschreibt alleinig was zwischen Server und Client transportiert wird, und welche Protokolle dabei verwendet werden. Was jedoch hinter den Applikationsservern für Server stehen, bleibt dem Client total verborgen. Bitte differenziert doch mal endlich zwischen Hardware-Architekturen und Software-Architekturen, und entscheidet Euch in welchen Artikeln ihr was wie beschreibt. --178.197.232.25 01:06, 2. Mär. 2013 (CET)

In der Tat! Der Artikel liest sich wie zusammengeschusterte Fachbegriffe, wie man sie sonst nur auf den Entscheidungsvorlagen fürs Management findet :-) --195.81.26.188 10:50, 5. Jun. 2013 (CEST)

WP:Sei mutig und widerspreche dem Management und verbessere den Artikel. --Sebastian.Dietrich ✉ 18:47, 5. Jun. 2013 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.dfpug.de/konf/konf_1998/09_tier/d_tier/d_tier.htm
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Netzwerk-Fehler (7) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/http://www.dfpug.de/konf/konf_1998/09_tier/d_tier/d_tier.htm

– GiftBot (Diskussion) 13:13, 28. Dez. 2015 (CET)

Dependency Injection Schicht???

@MovGP0: Noch nie davon gehört und auch noch nie gesehen (und ich habe 100e Schichtenarchitekturen gesehen). Wenn es sowas geben sollte, dann brauchts mehr / andere Belege als aus einem DI Buch. Die "oberste Schicht" gehört auch belegt. --Sebastian.Dietrich  ✉  08:09, 21. Mär. 2022 (CET)