Laden...

Diskussion zum Artikel: Drei-Schichten-Architektur

Erstellt von malignate vor 9 Jahren Letzter Beitrag vor 9 Jahren 17.193 Views
Hinweis von Coffeebean vor 9 Jahren

Abgetrennt von [Artikel] Drei-Schichten-Architektur

malignate Themenstarter:in
742 Beiträge seit 2005
vor 9 Jahren

Das ist vll. bisschen Offtopic, aber ich finde es schwierig, Architektur beizubringen / zu erläutern, weil das oft auch eine Frage der (teilweise subjektiven) Kosten ist.

Beispielsweise: In einem kleinen Migrationstool habe ich evtl. höhere Kosten durch gute Architektur als durch schlechte. In einem großen Projekt fallen Migrations- und Änderungskosten aber ganz anderst ist Gewicht. Diese Kosten können auch Subjektiv sein (meine Klassen werden zu groß, ich verstehe meinen eigenen Code nicht mehr). Und dann ist gerade Separation of Concerns das Mittel der Wahl. Wenn man so ein Thema näher bringen will, muss man vor allem hier Argumentieren.

In den guten Vorträgen wird das deutlich, beispielsweise hier zu CQRS: https://www.youtube.com/watch?v=JHGkaShoyNs

P
1.090 Beiträge seit 2011
vor 9 Jahren

Bei den 3 Schichten handelt es sich erst mal um eine Logische Trennung. Bei kleinen Projekten kann das auch in der selben Solution (dll) sein. Da beträgt der mehr Aufwand dann, 2x rechte Maustaste, Klasse hinzufügen und die beiden Klassen zu Instanzieren. Was wohl jetzt nicht zu viel ist.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

H
2 Beiträge seit 2015
vor 9 Jahren

Guter Artikel... Vielen Dank...
Es wäre vielleicht nicht schlecht einen Vergleichsartikel zu schreiben zum Thema MVC (Model-view-controller). Es wird oft zu recht auf den ersten Blick verwechselt mit dem 3-tier Model.
LG

P
1.090 Beiträge seit 2011
vor 9 Jahren

MVC ist ein Presentation Pattern und hat nicht direkt was mit einer Schichtenarchitektur.
Da sollte man nichts verwechseln, ansonsten sollte man sich nochmal in Ruhe die Grundlagen anschauen.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

5.299 Beiträge seit 2008
vor 9 Jahren

Hmm - dann presche ich mal vor, mit einer einfachen Beispiel-Anwendung ohne 3-Tier.
"ProductCatalogue" präsentiert Produkte mit ihren Preisen, und rechnet auch die Summe.
Laden, Speichern, Löschen, Zufügen, Editieren - also CRUD wird unterstützt, wie sich das gehört. 😁

Ich habe sogar 2 Varianten verfasst: 1."MostSimple" präsentiert einfach im Datagridview - das kann ja von Haus aus CRUD. 1."WithDialogs" weist mehr Benutzerführung auf, indem es zwar in einem (funktions-beschränkten) DGV präsentiert, aber zum Editieren/Zufügen muss man einen Extra-Dialog öffnen.

Ich hätte auch ein Beispiel einbringen können, beruhend auf einem komplexeren Datenmodell - etwa das Form2Form überdenken beiliegende Projekt, oder das von Databinding-Übungen, was sich in mehreren Forms präsentiert.

Aber ich stelle mit "ProductCatalogue" extra ein besonders einfaches Beispiel in den Raum, damit die Umarbeitung in eine 3-Schichten-Architektur hofflich nicht so aufwändig wird für den, der sich daran versuchen mag 🙂

Wer also findet, man könne hier sinnvoll eine 3-Schichten-Architektur implementieren, ist aufgerufen, seine Version vorzulegen.
Ansonsten sind es eben Beispiele für Anwendungen, bei denen eine 3-Schichten-Architektur nicht sinnvoll erscheint.
Das ist ja meine provokante These, dass in vielen oder gar sehr vielen Fällen der 3-Tier-Pattern eine Anwendung eher verschlechtert als verbessert.

Der frühe Apfel fängt den Wurm.

5.657 Beiträge seit 2006
vor 9 Jahren

Hi ErfinderDesRades,

ich weiß nicht so richtig, was ich mit deinem Beitrag anfangen soll. Du postest in einem Artikel über die Drei-Schichten-Architektur ein Projekt ohne Drei-Schichten-Architektur, für das dir die Drei-Schichten-Architektur nicht sinnvoll erscheint und stellst die These auf, daß die Drei-Schichten-Architektur generell nicht sinnvoll sein sollte...?

Nimm mir's nicht übel, aber das kommt ein bißchen wie ein Trollversuch rüber...

Das ist ja meine provokante These

Provokante Thesen stellt man nicht einfach in den Raum. Man sollte sie auch begründen. Besonders, wenn wirklich gute Gründe für die Drei-Schichten-Architektur im Artikel genannt werden.

Christian

Weeks of programming can save you hours of planning

5.299 Beiträge seit 2008
vor 9 Jahren

Meine Argumente hab ich glaub in post#2 dargelegt.
Das ist eine böse Verfälschung, wenn du behauptest, ich hätte behauptet, 3-Schichten-Architektur sei generell nicht sinnvoll.
Bitte nochmal nachlesen, was ich gesagt habe.

Mein Wunsch ist nicht, als Troll verunglimpft zu werden, sondern ich nehme diejenigen beim Wort, die behaupten, ein überzeugendes 3-Schichten-Beispiel liefern zu können - was ich leider nicht kann.
Mir erscheinen meine eigenen Versuche von 3-Tier umständlich und architektonisch schlechter, als es eben so simpel zu machen, wie ichs halt gemacht hab, und hier zur Verfügung stelle.
Ich bitte diejenigen, die es können, darum, es mir zu zeigen.
Ich selbst kann nur eine "ungeschichtete" Vorlage liefern, über die man vlt. reden kann: ob und warum 3-Tier dort nicht funktioniert, oder ob doch, und wie es dann aussähe.

Aber selbst wenn sich niemand finden sollte, der es kann, oder bereit ist, sich (wie ich) die Mühe zu machen, eine geschichtete Alternative zu meinem Sample vorzulegen, ist mein Beitrag deshalb nicht OffTopic.
Meine Meinung ist, ein Artikel über 3-Schichten-Architektur muss auch eine begründete und mit Beispiel untermauerte Stimme aushalten können, die sich untersteht, dieses fabelhafte Instrument zu relativieren.

Der frühe Apfel fängt den Wurm.

5.657 Beiträge seit 2006
vor 9 Jahren

Das ist eine böse Verfälschung, wenn du behauptest, ich hätte behauptet, 3-Schichten-Architektur sei generell nicht sinnvoll.

Der von mir zitierte Text im Kontext:

Das ist ja meine provokante These, dass in vielen oder gar sehr vielen Fällen der 3-Tier-Pattern eine Anwendung eher verschlechtert als verbessert.

Wenn es eine Verfälschung ist, dann bestimmt keine bösartige.

Ich bitte diejenigen, die es können, darum, es mir zu zeigen.
Ich selbst kann nur eine "ungeschichtete" Vorlage liefern, über die man vlt. reden kann: ob und warum 3-Tier dort nicht funktioniert, oder ob doch, und wie es dann aussähe.

Das Anliegen wäre meiner Meinung nach im Code-Review-Forum besser aufgehoben.

Christian

Weeks of programming can save you hours of planning

49.485 Beiträge seit 2005
vor 9 Jahren

Hallo ErfinderDesRades,

wenn man davon ausgeht, dass die allermeisten Anwendungen, die geschrieben werden, kleine Programme, Tools oder Apps sind, dann hast du mit der Aussage, "dass in vielen oder gar sehr vielen Fällen der 3-Tier-Pattern eine Anwendung eher verschlechtert als verbessert", vielleicht sogar recht, zumindest wenn die angesprochenen Programme auf Dauer klein bleiben.

Trotzdem denke ich, dass deine Behauptung geeignet ist, einen falschen Eindruck zu erwecken, denn sobald wir über größere Programme, Anwendungen und Projekte reden, sieht es ganz anders aus. Dort wird eine Schichtentrennung in regelmäßig mehr Vor- als Nachteile bringen.

Nur ist es schwer bis unmöglich ein Beispiel zu erstellen, das so groß ist, dass sich die Vorteile zeigen, zumal sich diese weniger im Code selbst als bei der Arbeit mit dem Code zeigen.

Aus meiner Sicht hat und behält der Artikel von MrSparkle seine volle Berechtigung, selbst wenn niemand ein solches Beispiel liefert. Die Schichtentrennung ist eins der grundlegensten, wichtigsten und anerkanntesten Architekturmodelle der Software-Entwicklung und wird es wohl noch sehr lange bleiben.

herbivore

5.299 Beiträge seit 2008
vor 9 Jahren

Zunächst mal: Ich stelle das Schichten-Modell nicht in Frage, und spreche diesem Artikel nicht seine Berechtigung ab.

Woran ich hänge, ist der Versuch zu klären, wann 3-Tiers angemessen sind, und aber auch zu klären, wann nicht - zumindest ansatzweise.
Ich finde dieses Modell nämlich sehr oft empfohlen, auch Anfängern empfohlen, auch in Fällen, wo zB eine nennenswerte Business-Logik nicht absehbar ist.
Sodass man imo den Eindruck gewinnen kann (oder gradezu muss), 3-Tier sei immer vorteilhaft.
Was ich mit meinen Versuchen nicht in Einklang bringen kann, und das verunsichert mich, und da bin ich glaub nicht der Einzige, den das verunsichert.

Also würde mich freuen, wenn wir da konstruktiv weitermachen könnten, einen Vorschlag zur Bestimmung hätte ich schon:
"3-Tier sind (logischerweise) nicht sinnvoll, wenn eine nennenswerte Business-Logik gar nicht gegeben oder absehbar ist." - könnte man das so sagen?

Der frühe Apfel fängt den Wurm.

A
764 Beiträge seit 2007
vor 9 Jahren

Hallo ErfinderDesRades,

ich hatte mich tatsächlich an dein Projekt drangesetzt und hatte dabei festgestellt, dass die 3-Schichten-Architektur erst dann Sinn macht, wenn man das Projekt entsprechend erweitert wird.

Das habe ich jetzt nicht weiterverfolgt, werde das in den nächsten Tagen aber mal umsetzten.

Imho ein prima Beispiel, wie einem so eine Anwendung über den Kopf wachsen und durch 3-Schichten-Architektur wieder übersichtlich gemacht werden kann.

Gruß, Alf

49.485 Beiträge seit 2005
vor 9 Jahren

Hallo ErfinderDesRades,

aus meiner Sicht ist die Empfehlung zur Schichtentrennung auch und gerade für Anfänger wichtig, selbst wenn sie bei den kleinen Projekten, mit denen Anfänger üblicherweise beginnen, ihre Vorteile noch nicht ausspielt. Es ist deshalb wichtig, damit man von Anfang an eine Sensibilität für die Trennung der verschiedenen Zuständigkeiten bekommt, damit man über das nötige Wissen und die nötige Erfahrung in diesem Bereich verfügt, wenn man später größere Projekte angeht, bei dem die Schichtentrennung essenziell ist. Das dahinterstehende Prinzip, das man schon als Anfänger erlernen und beherzigen sollte ist Separation of concerns. Natürlich ist das nicht Selbstzweck, sondern resultiert aus der Erkenntnis, dass insbesondere die Wartung von Software erschwert wird, wenn die Zuständigkeiten vermischt sind, zumindest wenn die Software eine gewisse Komplexität übersteigt.

Dein Kriterium, die (nicht) Sinnhaftigkeit der Schichtentrennung von der (geringen) Komplexität der Business-Logik abhängig machen zu wollen, kann ich nicht folgen. Die Gesamtkomplexität hat sicher einen Einfluss, wie stark die Vorteile sind. Aber die Komplexität des GUIs sollte immer so gering wir möglich gehalten werden (wenn auch nicht einfacher als nötig). Auch wenn klar ist, dass eine hohe Wahrscheinlichkeit besteht, dass das sich die GUI-Technologie später ändern kann oder eine Anwendung von vornherein für verschiedene GUIs entwickelt wird, ist eine Schichtentrennung geboten bzw. notwendig. Und natürlich wird man gerade dann die Logik im GUI so gering wie möglich halten wollen, gerade weil das der Teil ist, der mehrfach für die unterschiedlichen Technologien entwickelt werden muss. Also gerade wenn man aus den genannten Gründen Schichtentrennung verwendet, wird es als Konsequenz keine nennenswerte Business-Logik geben. Schon deshalb kann eine geringe Komplexität des GUIs für sich genommen kein Kriterium gegen die Schichtentrennung sein.

Aus meiner Sicht Schichtentrennung für alle nicht-trivialen Programme und Projekte angebracht.

Und selbst bei trivialen Programmen ist für Anfänger die Schichtentrennung angebracht, um sie einzuüben.

herbivore

5.299 Beiträge seit 2008
vor 9 Jahren

Verstehe ich das recht, und als Antwort auf meine Frage von zuvor:
Also du würdest eine Logik-Schicht auch einziehen, wenn gar keine Logik da ist, und das so auch Anfängern empfehlen, und zwar, weil das das SOC-Prinzip einübt?

Also in solch einem Falle würde ich dem KISS-Prinzip den Vorrang geben, denn es kann nie richtig sein, einen Concern zu separieren, der nicht da ist. Abgesehen davon, dass es sehr schwer ist, sowas richtig umzusetzen, erschwert es auch die Wartung erheblich, denn wenn man später reinguckt, wird man Code vorfinden, der bei genauerer Betrachtung rein gar nichts macht - nach meiner Erfahrung sind solche Codes sogar schwerer zu verstehen als Codes, die etwas falsch machen.

Der frühe Apfel fängt den Wurm.

5.657 Beiträge seit 2006
vor 9 Jahren

Hi ErfinderDesRades,

die immer wieder vorgebrachten, wichtigsten Argumente hast du leider bisher ignoriert. Wie willst du denn ein Projekt testen, wenn die Abhängigkeiten der einzelnen Funktionen nicht voneinander getrennt sind? Wie willst du ein Projekt im Team entwickeln, wenn es keine Trennung der Verantwortlichkeiten im Code gibt?

Es geht also nicht um die Frage, ob sinnvoll oder nicht. Sobald man im Team oder überhaupt an kommerzieller Software arbeitet, ist das nicht mehr fakultativ, sondern obligatorisch.

Die Frage ist also höchstens, wie man sich als Anfänger diese Herangehensweise erarbeiten kann, und ob ein kleines Beispiel-Projekt hier sinnvoll ist, um die Vorteile zu demonstrieren. Darauf habe ich selbst keine Antwort, und darüber können wir gerne diskutieren. Aber einfach "provokante Thesen" in den Raum werfen, und dann beleidigt reagieren, wenn die Thesen auch ernst genommen werden, ist dabei nur wenig zielführend.

Christian

Weeks of programming can save you hours of planning

5.299 Beiträge seit 2008
vor 9 Jahren

Es geht also nicht um die Frage, ob sinnvoll oder nicht. Sorry - mir geht es sehr wohl darum: Inwieweit ist es für den einen oder anderen Mehr- oder Weniger-Anfänger sinnvoll, sein (mutmasslich) Ein-Mann-Projekt in 3 Schichten zu separieren?
Und auch wenn mir die Art, wie man mir hier entgegenkommt, nicht gefällt, so erhalte ich dennoch (und bedanke mich hiermit dafür) wertvolle Anhaltspunkte, um diese meine Frage zu klären.
Bisher habe ich:1.Wenn BusinessLogik zu separieren ist 1.Wenn Concern-Implementationen auswechselbar sein sollen 1.Wenn mit standardisierten Testverfahren entwickelt wird 1.Wenn Entwicklerteams an großen, kommerziellen Projekten arbeiten

Der frühe Apfel fängt den Wurm.

P
1.090 Beiträge seit 2011
vor 9 Jahren

Hallo ErfinderDesRades,

ich hab jetzt mal auf möglichst einfache Art dein Beispiel genommen und in 3-Schichten aufgeteilt. Gut die Buissiness Schicht macht jetzt nicht wirklich viel. Dafür gab es es da dann auch nur eine Extension Methode. VS gibt mir jetzt an, das das Projekt jetzt 136 statt 128 Codezeilen hat. Ich denke der Mehraufwand ist überschaubar.

3-Schichten machen natürlich nur Sinn, wenn du auch wirklich Sachen hast, die du in diese Schichten aufteilen kannst. Wenn du nur Daten und keine Logik hast, kannst du die Bussiness Schicht weg lassen und die Daten direkt anzeigen.

Der wichtige Punkt ist einfach Anzeige, Logik und Datenhaltung so gut wie möglich von einander zu trennen und die Abhänigkeiten nur in eine Richtung gehen zu lassen.

MFG
Björn

p.s. Sorry hat jetzt bei mir was länger gedauer.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

5.299 Beiträge seit 2008
vor 9 Jahren

Vielen Dank!

Und guck - ist auch kein weiter Hexenwerk, und verkompliziert auch nichts weiter: Einfach 2 Methödchen woanders hingepackt, und dann sinds 3 Schichten.
Kommen mehr Methoden, so hat man eine Vorstellung, wo sie hinkommen, und kommen keine weiteren, ist auch gut.

Vielen Dank nochmal - ich wär halt im Leben nicht drauf gekommen, dass es sowas simples ist (oder sein kann), was mit den 3 Schichten gemeint ist.

Sicherlich kann man auch mehr Aufwand treiben, Abhängigkeiten entkoppeln, auslagern in eigene Assemblies etc. - aber das bischen Projekt würde den Aufwand nicht rechtfertigen, und dass die Anlage erkennbar ist (scheint mir zumindest so), ist wohl die Hauptsache.

(Also ich hoff jdfs., dass du's "richtig" gemacht hast - nicht dass ich jetzt falschen Vorstellungen von 3 Schichten anhange)

Der frühe Apfel fängt den Wurm.

P
1.090 Beiträge seit 2011
vor 9 Jahren

Gern geschehen.

Wie geasgt wichtig ist erst mal die Logische Trennung und die kann man auch bei kleinen Projekte ohne viel aufwand umsetzen. (Ganz sauer ist es jetzt nicht, ich denk mal, das Update des gesamt Preises, nach dem hinzufügen von einem Artikel, könnte man noch als Logic bezeichnen. Und ich denke mal das es noch X Sachen gibt die man besser hätte umsetzen können. Mir war es jetzt wichtig zu zeigen das es relative einfach geht.)

Bei größeren Projekten sollte sicher mehr aufwand reingesteckt werden.
Ich persönlich halte es aber erstmal für wichtig, das die grundlegende Aufteilung verstanden wird. Das ändert schon mal einwenig die Sicht auf die Dinge.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

49.485 Beiträge seit 2005
vor 9 Jahren

Hallo ErfinderDesRades,

Also du würdest eine Logik-Schicht auch einziehen, wenn gar keine Logik da ist, und das so auch Anfängern empfehlen, und zwar, weil das das SOC-Prinzip einübt?

So ist es.

Also in solch einem Falle würde ich dem KISS-Prinzip den Vorrang geben

Die Formulierung "den Vorrang geben" zeigt, dass hier zwei Prinzipien gegeneinander stehen, von denen man das eine nicht umsetzen kann, ohne das jeweils andere einzuschränken oder aufzugeben und man daher eben abwägen muss, welchem Prinzip man den Vorrang gibt.

Bei Anfängern geht es vor allem um den Lerneffekt. Und da finde ich die Sache klar. Wenn ein Anfänger zuerst KISS (und nur KISS) lernt und man ihm später (wenn er schon bei größeren Projekten ist) sagt, mach mach SOC, dann steht er vor einen Problem. SOC schüttelt man nicht eben so aus dem Handgelenk. Wenn er aber zuerst SOC lernt und man ihm später bei einem (weiteren) kleinen Projekt sagt, hier lohnt sich der Aufwand für SOC nicht, mach es KISS, dann wird ihm das leicht fallen. Schon deshalb erst SOC lernen, dann KISS.

denn es kann nie richtig sein, einen Concern zu separieren, der nicht da ist.

Das stehe ich anders. GUI-Code ist immer ein von der Business-Logik separater Concern, egal wie viel oder wie wenig (GUI-)Logik im GUI-Code steckt.

Abgesehen davon, dass es sehr schwer ist, sowas richtig umzusetzen, erschwert es auch die Wartung erheblich, ...

Nachdem, was ihr beiden über das Beispiel von Palin geschrieben habt, gehe ich davon aus, dass du nicht mehr dieser Meinung bist. Im Gegenteil erscheint dir der Code mit Trennung wohl jetzt sogar klarer. Du schreibst "Kommen mehr Methoden, so hat man eine Vorstellung, wo sie hinkommen". Das spricht auf jedenfalls für mehr Klarheit, Übersichtlichkeit und leichtere Wartung, was auch meine persönlichen Erfahrung bei größeren Projekten entspricht.

herbivore

PS: Für mich basiert die ganze Diskussion im wesentlichen auf einem - gar nicht böse gemeint - anfänglichen Un- bzw. vielleicht auch nur Missverständnis und sollte - schon wegen ihrer Länge und ihren Wendungen - abgetrennt werden. Stattdessen könnte in diesem Artikel-Thread hier besser eine kurze Zusammenfassung des Ergebnisses der Diskussion stehen. Aus dieser Zusammenfassung kann natürlich auf die dann abgeteilte Diskussion verlinkt werden.

S
8 Beiträge seit 2015
vor 9 Jahren

Hallo,

ich habe auch das Beispiel "Product" von ErfinderDesRades in ein 3 Schichtenmodell umgesetzt.

Nur fehlt mir jetzt noch die GUI, bzw den ViewModel beim WPF 😄.. Kann jemand das noch vervollständigen?

Gruß,

SehrScharf

F
10.010 Beiträge seit 2004
vor 9 Jahren

Du kommst bestimmt von C/C++.
Destruktoren braucht man in C# sehr selten, und schon gar nicht wenn man nur mit verwalteten Strukturen arbeitet.

Schau dir das IDisposable pattern an, wenn da tatsächlich mal was zum freigeben wäre, was in deinem Beispiel nicht der Fall ist.
So wie du es implementiert hast, ist nicht sichergestellt das der Destructor überhaupt aufgerufen wird.

Auch ist


_productAccess.Load();
_productList = _productAccess.ProductList;

eher unüblich, eher


_productList = _productAccess.LoadProductList();

Ob das intern gecached wird, sollte egal sein.

S
8 Beiträge seit 2015
vor 9 Jahren

Ich habe den Dekonstruktor benutzt, um vor dem Zerstörens der Objektes die Produktliste in eine Datei abzuspeichern. Mehr hatte ich auch nicht vor.

16.806 Beiträge seit 2008
vor 9 Jahren

Das ist nicht wirklich fein. Wenn man das nicht anders Lösen kann, dann nimmt IDisposable dafür - nicht direkt den Dekonstruktor.

S
8 Beiträge seit 2015
vor 9 Jahren

Warum soll man den Dekonstruktor nicht verwenden, um abschließende Arbeiten zu erledigen?

Ich bin der Meinung, dass zu eine guten Argumentation auch ein Codebeispiel dazu gehört.

Gruß,

SehrScharf

P
1.090 Beiträge seit 2011
vor 9 Jahren

Ich bin der Meinung, dass zu eine guten Argumentation gute Argumente gehören. 😉

Und da ist IDisposable der Gewinner. Lese dir doch mal auf der MSDN den Artikel dazu durch, dann wirst du auch verstehen wie so man es verwenden sollte.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

F
10.010 Beiträge seit 2004
vor 9 Jahren

@SehrScharf:
Deshalb sagte ich ja, du kommst wahrscheinlich von C/C++.
Nur weil C# eine ähnliche Syntax hat, solltest du nicht meinen irgendetwas übernehmen zu können.
In .NET ist nicht sichergestellt wann oder das der Destruktor überhaupt aufgerufen wird.
Destructor vs IDisposable?

5.657 Beiträge seit 2006
vor 9 Jahren

Hallo allerseits,

Also du würdest eine Logik-Schicht auch einziehen, wenn gar keine Logik da ist

Ich hab echt lange überlegen müssen, aber mir ist kein Beispiel dazu eingefallen. Kann denn ein Programm ohne Geschäftslogik überhaupt nützlich sein? Selbst ein einfacher Textdatei-Betrachter hat eine Suchfunktion, die mit den Daten des Modells eine Operation durchführt und die in der BL implementiert sein sollte.

Ich kann mir Beispiele vorstellen, bei denen die Präsentationsschicht fehlt (z.B. ein Dateikonverter) oder die Datenzugriffsschicht (z.B. eine Taschenrechner-App). Aber was bleibt von einer Anwendung ohne Geschäftslogik übrig?

Christian

Weeks of programming can save you hours of planning

16.806 Beiträge seit 2008
vor 9 Jahren

Ich bin der Meinung, dass zu eine guten Argumentation auch ein Codebeispiel dazu gehört.

Wow. Interessante Argumentation. 🤔
Schau Dir doch einfach erst mal IDisposable an bevor Du darüber urteilst. Evtl verstehst Du dann direkt das Prinzip und die Einwände, die dazu auf FZelle genannt hat.

P
1.090 Beiträge seit 2011
vor 9 Jahren

Ich hab für einen Kunden ein Test Tool "geschrieben" um einträge in eine DB Tabele manipulieren zu können. Da hab ich einfach die Entitäten an die UI gebunden.

Bei Listen ansichten kann man es sich auch vorstellen, das z.B. die DB die Suche macht und dann nur das Ergebnis dargestellt wird.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

S
8 Beiträge seit 2015
vor 9 Jahren

Ich bin der Meinung, dass zu eine guten Argumentation auch ein Codebeispiel dazu gehört.
Wow. Interessante Argumentation. 👶
Schau Dir doch einfach erst mal IDisposable an bevor Du darüber urteilst. Evtl verstehst Du dann direkt das Prinzip und die Einwände, die dazu auf FZelle genannt hat.

Ok hab durchgelesen. Das mit den Deskruktor bei C# habe ich wirklich nicht gewusst..