AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

debuggen einer MVVM Anwendung,

Ein Thema von bernhard_LA · begonnen am 22. Dez 2017 · letzter Beitrag vom 25. Dez 2017
Antwort Antwort
bernhard_LA

Registriert seit: 8. Jun 2009
Ort: Bayern
713 Beiträge
 
Delphi 10.1 Berlin Professional
 
#1

debuggen einer MVVM Anwendung,

  Alt 22. Dez 2017, 15:33
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
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.369 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#2

AW: debuggen einer MVVM Anwendung,

  Alt 22. Dez 2017, 15:59
(Ich versteh die Frage nicht)

Natürlich hat die UI noch eine Verbindung (Bindings o.ä.) zur Geschäftslogik - nur keine im Code hart kodierte.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
3.564 Beiträge
 
Delphi XE3 Ultimate
 
#3

AW: debuggen einer MVVM Anwendung,

  Alt 22. Dez 2017, 16:14
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).
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von mael
mael

Registriert seit: 13. Jan 2005
329 Beiträge
 
Delphi XE3 Professional
 
#4

AW: debuggen einer MVVM Anwendung,

  Alt 22. Dez 2017, 18:13
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.
HxD, schneller Hexeditor:
http://mh-nexus.de/hxd

Geändert von mael (22. Dez 2017 um 18:44 Uhr)
  Mit Zitat antworten Zitat
bernhard_LA

Registriert seit: 8. Jun 2009
Ort: Bayern
713 Beiträge
 
Delphi 10.1 Berlin Professional
 
#5

AW: debuggen einer MVVM Anwendung,

  Alt 22. Dez 2017, 22:17
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.
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
3.564 Beiträge
 
Delphi XE3 Ultimate
 
#6

AW: debuggen einer MVVM Anwendung,

  Alt 22. Dez 2017, 22:26
Ist in Berlin noch CodesiteLogging dabei?
Das ist doch ganz brauchbar.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Rainer Wolff

Registriert seit: 25. Okt 2005
Ort: Bretten
202 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#7

AW: debuggen einer MVVM Anwendung,

  Alt 24. Dez 2017, 19:59
Ist in Berlin noch CodesiteLogging dabei?
Das ist doch ganz brauchbar.
Zu dem Thema hatte ich kürzlich einen Thread aufgemacht:
CodeSite Express im GetIt-Manager verschwunden
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
6.045 Beiträge
 
Delphi XE4 Professional
 
#8

AW: debuggen einer MVVM Anwendung,

  Alt 25. Dez 2017, 13:55
Halloween
OutputDebugString sollte doch reichen?
Heiko
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:19 Uhr.
Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2017 by Daniel R. Wolf