debuggen einer MVVM Anwendung,

[bernhard_LA]

Wenn meine Geschäftslogik keine Verbindung mehr zu UI hat, wie suche ich dann Laufzeitfehler in meiner Anwendung, Da ich ja Informationen über die aktuellen Daten die zum Laufzeitfehler führen nicht mehr vernünftig ausgeben kann

[Stevie]

:gruebel: (Ich versteh die Frage nicht)

Natürlich hat die UI noch eine Verbindung (Bindings o.ä.) zur Geschäftslogik - nur keine im Code hart kodierte.

[stahli]

Ist das jetzt eine rein theoretische Frage oder schon irgendwie praktisch begründet?

Das Debugging der BL kann letztlich ohne angebundene Views erfolgen. Natürlich muss der falsch ablaufende Prozess/Methode irgendwie angeschoben werden.

Wenn die Views und Bindings nicht korrekt funktionieren ist das Debugging schwieriger. Dann ist das Aufgabe des Framework-Herstellers (irgendein Framework muss ja eingesetzt sein, egal ob nativ in der IDE vorhanden oder nachträglich eingebunden).

[mael]

Zitat:

Zitat von bernhard_LA (Beitrag 1389508)

Wenn meine Geschäftslogik keine Verbindung mehr zu UI hat, wie suche ich dann Laufzeitfehler in meiner Anwendung, Da ich ja Informationen über die aktuellen Daten die zum Laufzeitfehler führen nicht mehr vernünftig ausgeben kann

Wenn man WPF als Beispiel nimmt, so wird in XAML (so ähnlich wie DFMs) das Aussehen der GUI beschrieben, aber auch die Bindung an das ViewModel.

Das ViewModel hält die Daten für die GUI in einer möglichst geeigneten Weise vor. Z.B. eine Liste von Personen (TPersonList), eine aktuell ausgewählte Person (TPerson), und ein Kommando (ähnlich zu TAction) die eine Suche ausführt.
Pseudocode:

Code:

TViewModel = class
  property SelectedPerson: TPerson;
  property PersonList: TPersonList;
  property SearchPersonsCommand: ICommand;
  property SearchResultList: TPersonList;
end;

Die GUI wird immer aktualisiert wenn diese Eigenschaften sich ändern (also z.B. eine neue Person hinzugefügt wird, oder die ausgewählte Person sich ändert). Umgekehrt werden Änderungen der GUI zurück ins ViewModel geschrieben (z.B. wenn TEdit.Text geändert wird der den Namen einer Person enthält). Bindings erlauben es dies mit loser Kopplung zu erreichen, da weder GUI noch ViewModel voneinander wissen müssen.

Der Trick bei Bindings ist dass man gewisse Formalismen im ViewModel einhält, so dass Bindings kurz und knapp ausdrückbar sind, oder auch im Objektinspektor schnell erstellbar sind. Z.B. hilft die RTTI der Eigenschaften den Datentyp zu bestimmen, und es gibt Standardmethoden Propertyänderungen zu beobachten.
Wenn das gut implementiert ist, sind Bindings quasi nur ein paar Klicks.


Das Debugging kann ganz klassisch erfolgen, wenn Bindings zu einer konkreten GUI bestehen (was man normalerweise gleich zusammen mit dem GUI-Entwurf macht).

Man kann aber auch das ViewModel direkt testen, denn dort ist ja schon die meiste Benutzerinteraktionslogik drin. Z.B. sollen nach einer Personensuche in einer DB alle Treffer aufgelistet werden (SearchResultList) aber auch der erste Treffer (erste Person) ausgewählt werden (also SelectedPerson gesetzt werden).


Das meiste was man also testen oder abfragen will ist im ViewModel. Zur visuellen Unterstützung kann man auch mit GUI testen.

Bindings selber zu testen ist zumindest in XAML schwierig, weil man nicht durch den XAML-Parser und Binder-Code steppen kann. Aber da gibt es Tricks wie z.B. das Hinzufügen von Value-Converters. Die werden bei jeder Bindung ausgeführt um von einem Datentyp zu einem anderen zu konvertieren (geht auch wenn z.B. beide int sind, man aber z.B. weiß, dass diese ints ineinander umgerechnet werden müssen).

Man kann dann einen Haltepunkte in die Value-Converter setzen um zu sehen ob die Bindung überhaupt ausgeführt wird bzw. wann dies geschieht.

[bernhard_LA]

der Fehler ist innerhalb der BL, die geschriebenen Testcases (DUNITX) sind pass, bei einigen Usecases tritt eine AV auf. Mit MADSHI bekomme ich zwar den Trace angezeigt auf die fehlerhafte Code Sequenz, nur wird diese schon vorher x 1000 durchlaufen, der Fehler will sich mir nicht zeigen.

Da die BL ja keine GUI Verbindung im MVVM Design mehr hat baue ich jetzt an vielen Codestellen Sequenzen ein um den Inhalt von möglichen fehlerhaften Variablen/Daten in Textdateien zum debugging abzuspeichern. Ich will keine temporäre Debugg GUI bauen.

Es wäre natürlich einfacher wenn ich in irgendeine Console oder eine memofeld Informationen schreiben könnte um so den Fehler herauszufinden.

DUNITX und ein die Möglichkeit aus der BL in die Commando Zeile zu schreiben wäre auch eine Option.

[stahli]

Ist in Berlin noch CodesiteLogging dabei?
Das ist doch ganz brauchbar.

[Rainer Wolff]

Zitat:

Zitat von stahli (Beitrag 1389528)

Ist in Berlin noch CodesiteLogging dabei?
Das ist doch ganz brauchbar.

Zu dem Thema hatte ich kürzlich einen Thread aufgemacht:
http://www.delphipraxis.net/194690-c...schwunden.html

[hoika]

Halloween
OutputDebugString sollte doch reichen?