Was sind genau Dokument-Klassen-Daten und was nicht

Hallo,

ich möchte ger mit dem Document/View Modell der MFC arbeiten. Hab mir auch schon einige Tutorials etc. durchgelesen. Allerdings ist mir eine Sache immer noch nicht ganz klar: Welche Daten gehören wirklich in die Dokumentenklasse und welche nicht?

a) laut Tutorials sind in der Dokumentenklasse alle Daten vorhanden, die in der View dargestellt werden können. Das finde ich immer sehr schwammig formuliert, weil das Konzept von C++ ist ja nicht an Klassen zu sparen sondern möglichst alles genau und getrennt aufzulisten. Es kann aber auch nicht sein, dass es der richtige Weg ist, alle anderen Klassen mit einer Membervarialbe in der Dokumentenklasse zu belegen.

Wie sieht es z.B. mit Schnittstellen aus. Eigentlich hatte ich es so vor, dass für jede Schnittstelle eine eigene unabhängige Klasse existiert, die diese Schnittstelle konfiguriert.

Als konkretes Beispiel z.B. die RS232 Schnittstelle. Jetzt soll es aber auch so sein, dass die Einstellungen für diese Schnittstellen in der View angezeigt werden. Hat jetzt die View Klasse, die für die Darstellung der Daten zuständig ist, direkten Zugang zu der RS232-Klasse? Und wenn nicht, inwieweit hat die Dokumentenklasse was mit den RS232-Daten zu tun?

Kann mir da jmd aus dem Dschungel raushelfen und etwas Klarheit geben?

Danke für eure Antworten

Johannes

Martin Richter

Der View hat keinen Zugang zum COM Interface. Das macht alles das Doc.
Der View zeigt nur die Daten aufbereitet an.

Das Doc/View Modell ist ein Modell. Nicht alles mag in dieses Modell passen.

CTecS

Besteht die Frage warum sollen die schnittstellen RS232 usw. nicht in das Doc passen, die Daten die verschickt oder empfangen werden, werden doch eh im Doc gehalten.

Was mit anderen Schnittstellen ist, kommt immer drauf an was die so machen, aber der View ist eben halt nur zur anzeige von Daten da, also kommen da nur schnittstellen in Frage die die Anzeige steuern.

Softwaremaker

Öffne mal MS Word oder OpenOffice Writer, gehe im Menü auf "Fenster" > "Neues Fenster". Nun hast du zwei Ansichten/Fenster des selben Dokuments, tippst du was in das eine Fenster, dann erscheint es automatisch im anderen Fenster auch. Das ist ein typisches Beispiel für Doc-View-Klassen. Es gibt nur ein Doc-Object (Daten: Text, Formatierung, Bilder) und ein oder mehrere View-Objekte (Fenster die Doc-Daten anzeigen). Würde man Daten in der View-Klasse speichern, dann wäre es umständlich die anderen Views zu updaten, da es mehrere View-Objekte sind und man müsste Daten zwischen diesen hin und herkopieren. Also alle Daten in die Doc und wenn eine Aktion in einem View stattfindet die Daten im Doc ändern und mit Doc->UpdateAllViews() werden automatisch alle Views des Docs aktualisiert.

Deine RS232-Klasse legst du einfach als Member-Variable in der Doc-Klasse an, dort liegen dann auch die Einstellungen usw.
Von jedem View hast du Zugriff auf das Doc mittels (MeineDocKlasse*)GetDocument().

Roger Wilco

Ich klinke mich mal in die Diskussion ein, da ich in den letzten Tagen mit der selben Frage "gekämpft" habe. Das Doc/View-Modell an sich ist klar, aber ich erstelle ehrlich gesagt das erste mal eine MDI-Anwendung. Daher plagen mich die gleichen Fragen.

Gehört eine Klasse, die eine Schnittstelle zum Datenaustausch bereit stellt, als Membervariable ins Dokument? Ich habe es in meinem Fall erstmal so gelöst, aber richtig wohl fühle ich mich dabei nicht.

Dann wären da noch die ganzen Befehle aus der Menü-Leiste, wie z.B. "Verbindung aufbauen", "Verbindung trennen" oder "Verbindungsdaten anzeigen". Wo soll der Handler der Befehle rein? Zur Zeit habe ich sie auch alle im Dokument, da sie die Verbindung betreffen und das Dokument diese auch "besitzt" und verwaltet.

Aber ist das Dokument nicht eigentlich mehr als reine (passive) Datenbasis gedacht?

Martin Richter

Alles ins Dokument. Das passt schon. Genau wie Datei-Öffnen/Speichern ja auch dort verankert ist. Ich sehe das ähnlich hier.

Roger Wilco

Wenn Du das sagst, dann wird das wohl so "richtig" sein.

Dann bin ich beruhigt und kann das innerlich abhaken...

Martin Richter

Roger Wilco schrieb:

Wenn Du das sagst, dann wird das wohl so "richtig" sein.

Ích muss Dich enttäuschen. Ich habe kein Abo auf richtige Antworten...

AndyDD

Ich möchte das Thema Schnittstellen noch mal aufgreifen. Die Klasse CSerial von Ramon de Klein (http://www.codeproject.com/KB/system/serial.aspx) wird doch in der MFC-Version aber rein in der View-Klasse eingesetzt, weil er sich dort doch an die Message-Map der Viewklasse hängen will. Oder sehe ich das falsch?
Generell würde ich das ja auch im Doc abhandeln.

Martin Richter schrieb:

Roger Wilco schrieb:

Wenn Du das sagst, dann wird das wohl so "richtig" sein.

Ích muss Dich enttäuschen. Ich habe kein Abo auf richtige Antworten...

Das stimmt sicher, aber Deine Meinung wird hier sehr oft und sehr hoch geschätzt.

Martin Richter

AndyDD schrieb:

Ich möchte das Thema Schnittstellen noch mal aufgreifen. Die Klasse CSerial von Ramon de Klein (http://www.codeproject.com/KB/system/serial.aspx) wird doch in der MFC-Version aber rein in der View-Klasse eingesetzt, weil er sich dort doch an die Message-Map der Viewklasse hängen will. Oder sehe ich das falsch?
Generell würde ich das ja auch im Doc abhandeln.

Wenn CSerialWnd verwendet wird, dann wird ein Fenster benötigt. Wnen er das im Sample an den View bindet dann ist dies "nicht schönes" Design aber schnell geschriebener Code.
Das Problem ist, dass CDocument nur WM_COMMAND Nachrichten bekommen kann. Keine anderen Windows Nachrichten!

Ich benutzte für solche Fälle ein versteckes Fenster (wenn ein Fenster notwendig ist) und definiere immer einer Callback Funktion (Interface) für meine CDocument Klasse, die die Events aufnimmt.
Da aber meisten die Serial I/O Klasse in einem eigenen Thread liegt (bei mit) habe ich solche Probleme selten...