Meinst Du sowas à la "Daten - Zwischenverwaltung - User Interface"?
Also praktisch sowas wie MVVM in WPF?

Ich hab mich zwar noch nie direkt damit befasst, aber ich habe mich mit dem MVVM-Pattern aus WPF befasst, und das kann man wohl als konkrete Umsetzung dieser Architektur ansehen.
Ne detailierte Beschreibung davon findest du hier, vielleicht hilft es dir ja.

Du meinst MVC

Model = Daten
View = GUI
Controller = Vermittler zwischen beidem

Ist eigtl ziemlich selbsterklärend, wenn du bspweise einen Bruchrechner programmierst, dann hättest du folgende Klassen:

View = Die Klasse wo die GUI etc ist (wäre jetzt bspweise Form1)
Controller = Das wäre eine Klasse Bruchrechner, die dann Methoden wie Addiere(Bruch1,Bruch2) etc hat (also wird aus der GUI Schicht gerufen)
Model = Das wäre bspweise die Klasse Bruch, die dann die Daten (also den Bruch bzw 2 Zahlen - Nenner und Zähler) beinhaltet.

Der Vorteil daran ist, dass du jede einzelne Schicht austauschen und damit sowohl die Fehlersuche vereinfachen kannst als auch, wenn du bspweise nur an der GUI rumfrickelst, nicht noch die Datenschicht umkrempeln musst.

Nun eigentlich ist eine Drei-Schichten-Architektur nicht das gleiche wie MVC. Eine Drei-Schichten-Architektur begrenzt sich nicht auf eine Software, Sondern mehrere Software-Systeme.
Wohingegen MVC nur das Konzept innerhalb einer Anwendung beschreibt. Eine Drei-Schichten-Architektur könnte dagegen wie folgt aussehen:

Client -> Middleware -> Server



Bei MVC dagegen hast du drei verschiedene "Schichten" innerhalb einer Anwendung, worin das Model die Businesslogik abbildet. MVc könnte innerhalb der Drei-Schichten-Architektur auf einer der Schichten angewandt werden.

Ein sehr verständliches Dokument dazu wäre beispielsweise: glossar.hs-augsburg.de/Schichtenarchitektur / java-forum.org/allgemeines-ee/…vc-3tier-architektur.html

Gibt es für das MVC auch noch einmal eine genauere Beschreibung? Das ist ja schon interessant, denn bisher habe Ich auch immer so programmiert, dass (fast) alles in einer Klasse war.

ichduersie schrieb:

Gibt es für das MVC auch noch einmal eine genauere Beschreibung? Das ist ja schon interessant, denn bisher habe Ich auch immer so programmiert, dass (fast) alles in einer Klasse war.

Wenn fast alles bei dir in einer Klasse war, dann hilft dir aber auch MVC nicht viel. Denn Grundlage für MVC ist nach wie vor ein sehr gutes Verständnis darüber worauf es in objektorientierter Programmierung ankommt, gerade was das Thema Kapselung betrifft.

Ansonsten als Beispiel:
tutorialspoint.com/design_pattern/mvc_pattern.htm

Netlogger schrieb:

Glaube aber nicht das ich da Fit genug dafür bin

Zu was genau? MVC oder der Drei-Schichten-Architektur?
Die Verwendung der Drei-Schichten-Architektur ist nicht zwangsläufig für jeden Anwendungsfall angemessen zu wählen.
Wenn du allerdings glaubst nicht Fit genug für MVC zu sein, dann solltest du dich mit den drei Schwerpunkten von OOP erst einmal intensiv beschäftigen:

- Kapselung
- Polymorphie
- Vererbung

MVC kann schon recht lohnenswert sein. Aber wie gesagt ist MVC nicht zu verwechseln mit der Drei-Schichten-Architektur. Beide ähneln sich, sind aber nicht das gleiche. Das eine tritt bei verteilten Systemen ggf. in Kraft, das andere eher schwerpunktsmäßig bei der Entwicklung EINER Anwendung (Kein verteiltes System).

Ich hab mich auch gelegentlich mit Architektur beschäftigt, bin aber mit MVC, MVP nie warm geworden.
Knackpunkte sind:

• Die Idee, View und Controlling zu trennen geht nicht auf. In glaub allen Controls (ausser vlt. Label) ist beides unaufteilbar vereint - deswegen heißen die Dinger ja Control, und nicht View.
  
• Die "fleischlose" Herangehensweise an Architektur-Fragen erzeugt meist nur Murx und Verwirrung. Man sagte mir, MVC sei ein Pattern für große Projekte (offensichtlich habe ich noch nie an einem solchen gearbeitet).
  Jedenfalls wenn man kein ernstzunehmendes Problem hat, für dass zB MVC eine überzeugende Lösung bringt, dann wird es Murx.
  Weil den falschen Pattern angewandt ist immer Murx, so "richtig" man ihn auch umsetzt. Und die Folge: Verwirrung, denn man stößt ja mit der Nase drauf, dass der Pattern Murx erzeugt hat. Aber gleichzeitig hopfen da meist paar "Architektur-Astronauten" Drumherum, die das nicht sehen können, und die das dann ganz toll finden, und das einzig wahre.
  Solche Architektur-Vorstellungen sind bischen wie bei des Kaisers neue Kleider, nur dass niemand lacht, wenn einer mal die schlichte Wahrheit ausspricht.
  

gugge auch Frage zu AnwendungsArchitektur

Ist ganz interessant, da halte ich auch obige Rede, und später wird es auch konkret, und geht auch um Architektur, die hochwirksam hilft, Komplexität aufzulösen - nur sorry: in die MVC/MVP - Schublade passt das leider nicht, selbst MVVM kann mans nur im allerweitesten Sinne nennen.

Edit by ErfinderdesRades: unnötiges Vollzitat entfernt

Ich denke das ist ganz davon abhängig in welcher Form MVC realisiert wird. Passives MVC (bestes Beispiel OXID Eshop) ist in dieser Hinsicht gut tauschbar was den View betrifft. Generell passives MVC. Das Controller und View recht nah aneinander verzahnt sind ist nun leider wahr.

Andere Frage, wenn du dich nicht mit MVC anfreunden kannst, welches Entwurfsmuster bevorzugst du eher? Eigentlich geht es doch in keinem Falle wirklich auf, dass die Komponenten austauschbar sind.

N3X schrieb:

Eigentlich geht es doch in keinem Falle wirklich auf, dass die Komponenten austauschbar sind.

Exakt das ist der Punkt.
Aber es gibt Entwurfsmuster, wo die Austauschbarkeit durchaus gegeben ist.
Wpf baut durchgängig auf dem MVVM-Pattern auf - also da hats Microsoft endlich gemerkt und eine Infrastruktur dafür geschaffen.
in WinForms anhange Ich selbst schon seit längerem einem Pattern ohne Namen, man könnte ihn den "Databinding-Pattern" nennen.
Lies einfach den verlinkten Thread sorgfältig durch, und gugge auch die angehängten CodeSamples. Da wird ich finde sehr deutlich, wie mittels Bindingsources ein Databinding-Bindegewebe zwischen Datenmodell und Oberfläche konstruiert wird.

Und auch in Wpf verfahre ich nur selten nach "richtigem" MVVM-Pattern - meist verschmelze ich Model und Viewmodel. Aber die View ist etwas davon ganz unabhängiges und austauschbares, und Databinding bildet eine Art "Bindegewebe".

Übrigens das mit den austauschbaren Komponenten ist nicht der Punkt: Klar kannste eine Combobox ohne jede weitere Änderung durch eine Listbox ersetzen, ja, dann haste dasselbe in Grün - aber wer will denn dasselbe in Grün?

Jdfs um eine funktional andere Oberfläche für dasselbe Datenmodell zu konstruieren, muss natürlich auch das Bindegewebe anders konfiguriert werden.
Der Punkt ist, dass Datenmodell und Daten (also dieselben, nicht die gleichen Daten) unverändert bestehen bleiben, und du kannst verschiedene Views dafür basteln, die verschiedene Zwecke verfolgen: Etwa Artikel anlegen, oder Artikel verkaufen - oder auch nachbestellen.
Und der Witz in WinForms ist für mich, dass man Oberfläche designed in Designern, inklusive der Bindegewebsschicht. Also bei gegebenem Datenmodell schreibt man keine Zeile Code für eine der 3 genannten Oberflächen, das klickst man einfach zusammen - zumindest die Rohform - die dann aber schoma arbeitsfähig ist.
gugge vier Views-Videos, wenns interessiert.