Dva: Wie implementiere ich Modellverschachtelung (Modularisierung)?

Das Geschäft läuft so,
Zum Beispiel gibt es 5 relativ unabhängige Produkte in der App, und jedes Produkt hat ein relativ unabhängiges Modell.

In diesem Fall ist nur eine einzelne Modellschicht sehr eng

Natürlich kann es auch im Namespace unterschieden werden, aber derzeit wird der Namespace direkt als Statusname verwendet (spezielle Symbole wie . können nicht verwendet werden).

Nur eine einzige Modellschicht ist sehr eng

Ich habe es nicht verstanden

@codering

Wenn Sie sich das Dokument ansehen, hat das Modell physisch nur eine Ebene. Wenn es eine große Anzahl von Modellen gibt, besteht wahrscheinlich ein Konflikt mit dem gleichen Namen des Namespace (insbesondere bei großen Projekten haben einige Modelle dieselbe Semantik) Dieses Mal müssen sie sich möglicherweise im Namespace befinden. Fügen Sie vorwiegend Präfixe hinzu, um zwischen Modulen zu unterscheiden.

Ich möchte also fragen, ob es ein besseres Modellverschachtelungs- oder Modularisierungsschema gibt.

Es wird nicht empfohlen, zu tief im Status zu verschachteln. Wenn Sie das Modell dennoch verschachteln, wird es komplizierter. Es scheint, dass ein Problem mit dem Design vorliegt.
Ich verstehe die Frage nicht. Können Sie mir eine einfache Demo geben?

Diese Frage ist grob verstanden. Gestern haben wir sie diskutiert. Es geht hauptsächlich um die Bedeutung des Modells. Es gibt zwei Tendenzen: der Ansicht zu folgen und der Geschäftseinheit zu folgen.

Aus der aktuellen Entwurfssicht sollte es angemessener sein, der Ansicht zu folgen, da der Status jedes Modells isoliert ist und alles im Modell seinem eigenen Status folgt. Aus dieser Perspektive ist es in der Tat besser, der Ansicht zu folgen. Dies In diesem Fall ist die Bedeutung des Modells Ansichtsmodell.

Auf diese Weise können diese vom Modell verwendeten geschäftlichen Ergänzungen, Löschungen, Überprüfungs- und Änderungseffekte in jedem verwendeten Modell vorhanden sein, zum Beispiel:

Es gibt Ansichten ABC, Geschäftseinheiten XYZ, wo:

A verwendet CRUD von XY
B verwendet YZs CRUD
C verwendet die CRUD von XZ

Unser Modell ist so konzipiert, dass es der ABC-Ansicht folgt, und es muss einige Redundanzeffekte enthalten. Beispielsweise ist Y gleichzeitig in AB vorhanden, und es kann Redundanz im Code geben. Unter einem anderen Gesichtspunkt sollte die Verwendung von Y in AB selbst keine Wiederverwendung berücksichtigen, und der wiederzuverwendende Aufrufprozess sollte auf die nächste Ebene, dh den Dienst, gestellt werden.

So wird die Organisationsstruktur:

  a
  b
  c
service
  x
  y
  z

Und die Struktur von modelA:

{
  effects: {
    *x() {
      yield call(serviceX);
    },
    *y() {
      yield call(serviceY);
    }
  }
}

Die Struktur von Modell B:

{
  effects: {
    *y() {
      yield call(serviceY);
    },
    *z() {
      yield call(serviceZ);
    }
  }
}

Später werde ich eine eher geschäftsorientierte Demo schreiben und einige Vorschläge für die Verwendung von Szenarien geben

@xufei braucht Anleitung wie Onkel

@xufei Kannst du aus deiner Demo lernen?Ich mache mir darüber in letzter Zeit Sorgen

Hat @xufei Demo es?

Hat @xufei Demo es?

Ich denke, es ist vernünftiger, sowohl ein Geschäftsmodell als auch ein Ansichtsmodell zu haben. Beispielsweise kann der aktuelle Benutzer ein Benutzermodell für die globale Verarbeitung haben.
Wenn andere Komponenten aktuelle Benutzerinformationen enthalten, stellen Sie einfach eine direkte Verbindung zum Benutzermodell her.Dies hängt von den geschäftlichen Anforderungen ab

@ liSong5713 Benutzerliste in die Benutzerdetailliste geklickt, Benutzerdetails in die Schlüsselverwaltung geklickt, ob diese im selben Benutzermodell platziert werden sollen

@lwbGH Dies hängt von Ihren Modellverantwortlichkeiten ab. Das Benutzermodell kann die grundlegende und häufig verwendete Information des aktuell angemeldeten Benutzers sein. Wenn Sie die detaillierten Informationen des Benutzers ändern möchten, z. B. das Protokoll des Vorgangs des Benutzers, können diese Informationen sein völlig anders als das Modell. Ich denke, die Modellaufteilung liegt in ein wenig:
Der Grad der Freigabe des Status der Ebenenkomponenten ist kompliziert, wenn eine einfache Seite einem Modell auf Seitenebene entspricht

Natürlich kann es auch im Namespace unterschieden werden, aber derzeit wird der Namespace direkt als Statusname verwendet (spezielle Symbole wie . können nicht verwendet werden).
Kann nicht als Schlüssel verwendet werden, Sie können _ verwenden. Derzeit sind wir im Namespace eingeschränkt. Modelle können nach Ansicht und Geschäft in Module unterteilt werden, der Namespace wird jedoch durch "Ordner_Dateiname" eingeschränkt.