recherche

Maison  >  Questions et réponses  >  le corps du texte

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

La scène est comme ceci :

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 ?

PHP中文网PHP中文网2740 Il y a quelques jours463

répondre à tous(4)je répondrai

  • 曾经蜡笔没有小新

    曾经蜡笔没有小新2017-05-16 17:08:22

    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.

    répondre
    0
  • 曾经蜡笔没有小新

    曾经蜡笔没有小新2017-05-16 17:08:22

    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分别是StoreAStoreB。可以写一个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的这个事件,就会顺序执行在StoreAStoreB

    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 :)🎜

    répondre
    0
  • PHP中文网

    PHP中文网2017-05-16 17:08:22

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

    répondre
    0
  • 曾经蜡笔没有小新

    曾经蜡笔没有小新2017-05-16 17:08:22

    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.

    répondre
    0
  • Annulerrépondre