Sollte ich Geschäftslogik auf einem Modell oder einem ViewModel implementieren

Wenn ich Geschäftslogik in einer MVVM-App verarbeiten. Soll ich das auf dem Model oder dem ViewModel machen?Sollte ich Geschäftslogik auf einem Modell oder einem ViewModel implementieren

Wenn ich zum Beispiel die Kosten neu berechnen möchte, nachdem ein Asset neu bewertet wurde, sollte ich dann mit dem Model arbeiten?

Gibt es stattdessen einen Vorteil beim ViewModel?

Was passiert, wenn ich eine Liste von ViewModels habe, aber ich möchte das in eine Liste von Modellen übersetzen, damit ich etwas verarbeiten kann? Ich könnte das Modell als eine Eigenschaft des ViewModel verfügbar machen (und damit die Liste der Modelle erstellen). Dies bedeutet jedoch, dass die Ansicht auf die Eigenschaften des ursprünglichen Modells zugreifen kann.

Quelle

2016-06-07 Mitkins

Fügen Sie es in das Modell, ViewModel ist meist nur auf Präsentation und Vermittler zwischen der Präsentation und dem Modell (Datenträger). Eine andere Verwendung von viewmodel ist, die Struktur des Modells nicht zu berühren, wenn Sie Felder hinzufügen möchten, die nicht in der Datenbank reflektiert werden sollen, fügen Sie sie im viewmodel hinzu. In diesem Fall ist das Modell unberührt – Sherlock

Falsche Gemeinschaft, das ist besser bei [Programmierer] (http://programmers.stackexchange.com/). – Toxantron

Der Zweck des Modells besteht darin, Ihre Geschäftsdomäne darzustellen (oder zu modellieren). Daher geht die Geschäftslogik definitionsgemäß in das Modell und nicht in das ViewModel.

Die Aufgabe des ViewModels besteht darin, Eigenschaften und Felder des Modells verfügbar zu machen und sie für den Verbrauch durch die Ansicht vorzubereiten.

Beispiel eine Bankanwendung. Das Modell kann ein Konto darstellen. Vielleicht hat das Model einen Kontostand. Die Aufgabe des Modells besteht möglicherweise darin, das Guthaben nachzuverfolgen und sicherzustellen, dass bestimmte Invarianten erhalten bleiben (z. B. wenn eine Abbuchung nicht über dem Guthaben liegt). Der Job des ViewModels besteht möglicherweise darin, die Balance in eine Zeichenfolge umzuwandeln, die in der Ansicht als Bindung verwendet wird.

Sie möchten so viel Logik wie möglich aus dem ViewModel heraushalten, damit Ihr Code wiederverwendbar und lose gekoppelt bleibt.

Quelle

2016-06-07 07:38:57 bodangly

Ich stimme damit nicht überein. Ein Modell sollte idealerweise nur Eigenschaften haben, weil Modelle die Daten repräsentieren. Ein ViewModel ist ein _ok_ Platz für BL. Ich würde die BL so weit wie möglich außerhalb der Modelle und der ViewModels halten. Was Ihre letzte Aussage betrifft, gilt das eher für Modelle als für ViewModels. ViewModels sind per Definition eng an Views gekoppelt. – gldraphael

Wenn das Modell die erforderlichen Daten für die Berechnung enthält, können Sie model.if verwenden, wenn das Modell keine Daten enthält. Create view-model and get to data die Berechnung (in Bezug auf Business-Logik)

, wenn Sie wollen, dass diese Daten zu übergeben Ansicht Modell sehen erstellen Sie verbessern die Wiederverwendung von Code Möglichkeiten

Quelle

2016-06-07 06:30:11

Verwenden Sie das Modell, wenn Sie einen Web-App bauen. und eine Ebene unter dem Modell, d. h. die Domain-Ebene, wenn Sie eine LAN/Desktop-App erstellen.

Ihr Problem - Kosten neu berechnen, nachdem ein Asset neu bewertet wurde - ist möglicherweise nicht nur ein Problem mit der Benutzeroberfläche. Eine Back-End-Anwendung möchte möglicherweise dasselbe tun (z. B. zum automatischen Importieren von Daten). Und dann haben Sie die Wahl, entweder eine Geschäftslogik zu duplizieren oder eine neue zu erstellen.

Nichts ist falsch mit dem gleichen Modell für das Back-End zu verwenden. Aber Modelle - besonders getrennte - sind in der Regel große Datenstrukturen, da sie alle Daten aus Referenztabellen mitbringen müssen (es sei denn, Sie möchten Rundreisen zum Server machen und Ihre GUI-Erfahrung opfern). Und dies kann sich auf die Leistung auswirken, wenn das Modell verwendet wird.

Quelle

2016-06-07 07:17:36

Mein Vorschlag ist es, Logik in eine Service-Schicht stattdessen. Dies ist eine mittlere Schicht zwischen Ansichtsmodell und Modell (die in einem realen objektorientierten Paradigma nur Eigenschaften enthalten sollte). So kann der richtige Lebenskreis sein: Modell anzeigen -> Service -> Modellhandling. Dies ermöglicht auch die Wiederverwendung von Business-Logik-Code durch andere View-Modell bei Bedarf

Quelle

2016-11-24 21:32:40

Das macht Sinn. Also, in diesem Fall, wie ist die Ansicht an Eigenschaften des Modells gebunden? Wenn die Ansicht an das Modell und nicht an das Ansichtsmodell gebunden ist, scheint das Ansichtsmodell irgendwie redundant zu sein. Wenn die Ansicht an das Ansichtsmodell gebunden ist, wie werden dann 2-Wege-Bindungen implementiert, sodass Modelländerungen, die vom Dienst ausgeführt werden, wieder in die Ansicht übertragen werden? –

Ansicht Grenzen Viewmodel. Ansichtsmodell ist oft: - Klasse Ansicht begrenzt, die Daten, die von Ansichtsmodell begrenzt enthält, und rufen die Serviceschicht - eine Umhüllung des Modells durch Sicht oder durch eine andere Ansichtsmodell verwendet, wie oben geschrieben - Serviceanruf der „reinen“ -Modell - Service gibt einige Daten zurück, die von Viewmodel bereitgestellt werden, das an View gebunden ist –

Das klingt nach einer guten Idee, aber wie implementieren Sie es? Zum Beispiel habe ich eine Methode namens 'UpdateTiming()', berechnet drei Eigenschaften. Anfänglich habe ich beim Refactoring mein ViewModel als Argument übergeben, damit es diese Werte setzen kann und die UI aktualisiert wird. Aber jetzt ist der Dienst eng mit dem ViewModel verbunden. Soll ich stattdessen das Modell als Argument übergeben und ein Tupel zurückgeben und dann die Eigenschaften im ViewModel aktualisieren? Scheint so viel extra Code. – Adam

Sollte ich Geschäftslogik auf einem Modell oder einem ViewModel implementieren

Antwort

Verwandte Themen