Xaml/DataContext/MVVM Architektur-Dilema

[Prof84]

volkard schrieb:

Prof84 schrieb:

Jetzt will ich das die eine Funktion die andere aufruft oder beide hintereinander aufgerufen werden in Xaml. Wer wenn ist egal.

Um möglichst viel Anwendungslogik in Xaml definieren zu können?

Generell stimme ich Dir zu.
Aber ein Funktionsaufruf in Xaml mehr macht den Kohl nicht fett.- Reiner Pragmatismus.

[MFK]

Prof84 schrieb:

Ja, aber wie??

<Button Command="{Binding TransferCommand}">

TransferCommand steht für ein Property, das ICommand implementiert. Und in dessen Execute-Methode tust du, was eben getan werden soll.

[Prof84]

MFK schrieb:

Prof84 schrieb:

Ja, aber wie??

<Button Command="{Binding TransferCommand}">

TransferCommand steht für ein Property, das ICommand implementiert. Und in dessen Execute-Methode tust du, was eben getan werden soll.

Bekommst trotzdem vielleicht nicht beide Funktionen ausgeführt. Aber ich tüfftel damit weiter ... mal kucken.

In der Zwischenzeit habe ich eine Lösung gefunden:

ViewModel_EnterRR temp = new ViewModel_EnterRR(rr_data);
            this.DataContext = temp;
temp.Ok_Transfer();

"Wir habe zusammen einen IQ von 360. Wir werden doch noch durch diese doofe Tür kommen!"
http://www.youtube.com/watch?v=a7p-AEIQUyY

[MFK]

Prof84 schrieb:

In der Zwischenzeit habe ich eine Lösung gefunden:

Wenns auch mit Code gehen darf, warum rufst du nicht direkt Ok_Transfer auf?

[Prof84]

MFK schrieb:

Prof84 schrieb:

In der Zwischenzeit habe ich eine Lösung gefunden:

Wenns auch mit Code gehen darf, warum rufst du nicht direkt Ok_Transfer auf?

Besser! Jetzt kann ich es zu einem Aufruf zusammenfassen.
Ja, manchmal ... Brett vorm Kopp! - Guilty!

Trotzdem werde ich Deinen Property-Ansatz weiterverfolgen.
Danke!

[asc]

Prof84 schrieb:

MFK schrieb:

<Button Command="{Binding TransferCommand}">

TransferCommand steht für ein Property, das ICommand implementiert. Und in dessen Execute-Methode tust du, was eben getan werden soll.

Bekommst trotzdem vielleicht nicht beide Funktionen ausgeführt. Aber ich tüfftel damit weiter ... mal kucken.

Wieso solltest du in dem Command nicht beide Funktionen ausgeführt bekommen? In deiner ICommand-Implementierung kannst du alles tun was du möchtest, du kannst dir sogar ein verkettetes Command aus mehreren ICommands implementieren wenn du es brauchst (Eine ICommand-Implementierung die wiederum einen Container von ICommands hält)...

Ich versuche jedenfalls alle Logik die nicht absolut von der UI abhängig ist auch nicht in der UI zu implementieren (Bei uns geht es nicht um eine UI, sondern darum die VM/Commands in möglichst vielen nutzen zu können [z.B. WPF, Xamarin.Forms, Windows 8...]).

[Prof84]

Ja, bei ICommand werden nur etwa 100 OS Funktionen abgedeckt.
Eine brauch dann keine davon zu sein z.B. VM, alle weiteren von diese 100 werden als Property angehängt.

Wie bereits volkard klar gemacht:
VM, XAML-Window und XAML-Window.cs sind ein monolithischer Block. Da bringt ein Aufruf mehr in XAML nicht um, weil ich ihn sofort finde. Deshalb werde ich bei einer kleinen Fliese nicht einen Tag für die Baustatik verballern - aka *wumm*! Passt scho'!
Kein Dogmatismus hier.

[asc]

Prof84 schrieb:

Ja, bei ICommand werden nur etwa 100 OS Funktionen abgedeckt.

Falsch. Schau dir bitte mal an, wie eine ICommand-Implementierung in den üblichen MVVM-Frameworks implementiert wird, in der MSDN gibt es ein solches Beispiel (Schau dir mal die RelayCommand-Klasse an, und die Verwendung derselben).

Du kannst ein ICommand alles machen lassen.

Prof84 schrieb:

Wie bereits volkard klar gemacht:
VM, XAML-Window und XAML-Window.cs sind ein monolithischer Block.

Bei dir vielleicht, ansonsten ist die Aussage aber schlicht falsch. Ich kann ein und das selbe ViewModel sowohl unter WPF, WinRT als auch Xamarin.Forms nutzen. Und da ist die View (+XAML) unterschiedlich, nicht aber das ViewModel und die Commands.

Und selbst auf einer UI-Technik kann es sinnvoll sein ein ViewModel für mehrere Views zu verwenden (Gleicher Datenaufbau aber unterschiedliche grafische Aufbereitung), oder umgekehrt unterschiedliche ViewModels (mit gleicher Schnittstelle) bei einer View (z.B. ein Bearbeitenfenster das nur Aspekte verändert, die mehrere ViewModels gleichermaßen unterstützen).

[Prof84]

OK, ok ... RelayCommand schau ich mir noch an.
Aber das Thema ist schon lange durch.

Wenig Zeit i.M.

[asc]

Prof84 schrieb:

Aber das Thema ist schon lange durch.

Mein Einwand ist auch nicht böse gemeint, ich selbst habe bislang aber keinen Vorteil, sondern nur Nachteile von Code im Xaml und der Codebehind (letzteres bis auf Initialisierung oder reine UI-Spezifische Ausnahmen) gefunden. Mag daran liegen das ich seit der Existenz von PCLs diese auch versucht habe zu Nutzen wo möglich.