mvc - Comment le code frontal gère-t-il la relation un-à-plusieurs entre les opérations utilisateur et le modèle?

Question

La scène est comme ceci :

• L'utilisateur a cliqué sur un bouton
• Un modèle doit être mis à jour
• Le modèle B doit être mis à jour
  ...

Une telle opération doit s'appuyer sur plusieurs modèles en même temps, donc ces codes ne seront pas écrits dans un certain modèle.
Il peut s'agir par exemple de Backbone, écrit en ViewController... Mais cette réutilisation de code n'est pas bonne, et la View sera chamboulée.
Ma solution actuelle consiste à utiliser un seul fichier pour collecter la plupart des opérations du modèle, mais le problème est que ce fichier continuera de croître en taille et en encombrement.
Alors, comment résoudre un tel problème ?

La question étendue est : comment organiser cette partie du code ?
Par exemple, j’ai utilisé la solution Flux de React et j’ai essayé de clarifier le processus, mais j’ai découvert que je ne savais pas où mettre cette partie du code..
Flux convertit les opérations des utilisateurs en actions et Store surveille ces actions via Dispatcher,
Lorsqu'une Action correspond à plusieurs Stores... le problème se pose :
Dois-je utiliser plusieurs actions pour correspondre respectivement aux magasins, ou une action doit-elle être surveillée par plusieurs magasins ?

Answer 1

Un utilisateur cliquant sur un bouton est essentiellement le même qu'un utilisateur accédant via une URL. Il s'agit d'une "entrée", donc le problème et le mécanisme de traitement sont les mêmes : surveiller "l'entrée" dans le code de la couche de vue et traiter certaines vues. les couches (telles que les composants de bouton) basculent, correction d'URL) les changements d'état interne, génèrent/extraient un niveau d'abstraction pur et supérieur (non lié à l'affichage des composants ou aux détails de l'URL), des données/messages, les diffusent à l'aide d'une sorte de mécanisme d'événement, puis il n'a rien à voir avec vous, alors s'il existe une couche contrôleur, écoutez ces événements dans cette partie du code et appelez les méthodes des objets de modèle correspondants (qui peuvent encapsuler les dépendances et les appels entre les objets de modèle eux-mêmes, mais la complexité un-à-plusieurs ici ne sera pas exposée à l'extérieur), et également surveiller les changements d'état de certains objets de modèle et appeler les méthodes des objets de vue correspondants (ou restituer le DOM virtuel). Tout est lié.

Par exemple, j'utilise généralement NervJS (modèle) + DermJS (vue) + URLKit (route). Les objets NervJS et DermJS ont leurs propres méthodes d'événement. De plus, un bus unifié peut également être transmis lorsque l'objet vue/modèle est. objet d'événement initialisé.

Lorsque vous écrivez un composant d'interface utilisateur, vous ne voulez bien sûr pas qu'il dépende d'un modèle spécifique. Lorsque vous écrivez un composant de modèle, vous ne voulez pas qu'il dépende d'une interface utilisateur spécifique, donc des liaisons telles que one-to. -beaucoup se trouvent à un autre endroit (en particulier le code de logique métier) est complété. L'objet de vue et l'objet de modèle n'ont pas besoin et ne doivent pas savoir combien et lesquels en ont, il est donc impossible de « plusieurs actions correspondent respectivement au magasin. ".

Quant aux problèmes de « fichier unique » et de « chaos en constante augmentation », c'est la même chose que la configuration des fichiers de routage. Vous pouvez vous référer à une expérience pertinente.

Answer 2

En évolution, si vous avez besoin d’une action pour correspondre à plusieurs magasins, c’est en fait facile à résoudre.
Lors de l'enregistrement du rappel dans le Store, vous pouvez répondre à cette action, et vous pouvez également modifier l'ordre correspondant via waitFor. waitFor来改变相应的顺序。

如果担心代码变乱的话，可以再单独写一个constants文件，定义好触发的事件名称就可以了。

举个例子：

点击一个按钮，触发send事件，会更新两个Store分别是StoreA和StoreB。可以写一个constants.js，先定义事件名称：

constants:

module.exports = {
    "ActionTypes": {
        "SEND": "SEND"
    }
};

然后在两个Store里面分别注册回调：

StoreA:

var AppDispatcher = require('path/to/disp'),
    constants = require('path/to/constants');

StoreA.dispatchToken = AppDispatcher.register(function(payload) {
    var action = payload.action;
    if (action.type === constants.ActionTypes.SEND) {
        // callback A
    };
});

StoreB:

var AppDispatcher = require('path/to/disp'),
    constants = require('path/to/constants');

StoreB.dispatchToken = AppDispatcher.register(function(payload) {
    var action = payload.action;
    if (action.type === constants.ActionTypes.SEND) {
        // callback B
    };
});

在触发点击事件的时候，在Action中触发Disp的这个事件，就会顺序执行在StoreA和StoreB

Si vous craignez une confusion dans le code, vous pouvez écrire un fichier constantes distinct et définir le nom de l'événement déclenché. 🎜 🎜Par exemple :🎜 🎜Cliquez sur un bouton pour déclencher l'événement send, qui mettra à jour deux Store, à savoir StoreA et StoreB. Vous pouvez écrire un constants.js et définir d'abord le nom de l'événement : 🎜 🎜constantes :🎜 rrreee 🎜Ensuite, enregistrez les rappels dans les deux Store respectivement : 🎜 🎜MagasinA :🎜 rrreee 🎜MagasinB :🎜 rrreee 🎜Lorsqu'un événement de clic est déclenché, l'événement de Disp est déclenché dans Action, et il sera exécuté séquentiellement dans StoreA et StoreB :)🎜

Answer 3

Lorsque cela se produit, je me demande généralement si je peux ajouter une couche entre eux.

Answer 4

Si vous ne l'avez pas vu, ou si vous l'avez vu mais avez oublié, voici un article qui mérite d'être lu :

Modèles pour l'architecture d'applications JavaScript à grande échelle

En termes simples, vous avez besoin de quelque chose de "conventionnel" pour que la vue et le modèle n'aient pas besoin de dépendre l'un de l'autre (qu'il s'agisse d'une dépendance 1:1 ou d'une dépendance 1:N).

Vous pouvez également utiliser des modèles d'événements et d'observateurs simples. Si la logique métier est complexe, utilisez un médiateur pour compléter la communication et la synchronisation entre les modules.

PS : La situation idéale est que chacun de vos modules ne connaît que lui-même (quels événements sont déclenchés, quels événements sont écoutés), et ne se soucie de rien d'autre, encore moins de l'instance de l'autre partie, ou de l'instance du médiateur.