mvc - How does the front-end code handle the one-to-many relationship between user operations and Model?
PHP中文网
PHP中文网 2017-05-16 17:06:22
0
4
413

The scene is like this:

  • The user clicked a button
  • A Model needs to be updated
  • B Model needs to be updated
    ...

Such an operation needs to rely on many Models at the same time, so these codes will not be written in a certain Model.
It may be, for example, Backbone, written in ViewController... But this code reuse is not good, and the View will be messed up.
My current solution is to use a single file to collect most of the Model operations, but the problem is that this file will continue to grow in size and clutter.
So how should such a problem be solved?

The extended question is, how to organize this part of the code?
For example, I used React's Flux solution and tried to clarify the process, but I found that I didn't know where to put this part of the code..
Flux converts user operations into Actions, and Store monitors these Actions through Dispatcher,
When one Actions corresponds to multiple Stores... the problem arises:
Should I use multiple Actions to correspond to Stores respectively, or should one Action be monitored by multiple Stores?

PHP中文网
PHP中文网

认证0级讲师

reply all(4)
曾经蜡笔没有小新

A user clicking a button is essentially the same as a user accessing through a URL. It is an "input", so the problem and processing mechanism are the same: monitor the "input" in the view layer code, and process some view layers (such as button components) toggle, URL correction) internal state changes, generate/extract pure, higher abstraction level (not related to view components or URL details) data/message, broadcast it using some kind of event mechanism, and then it has nothing to do with you. , then if there is a controller layer, listen to these events in this part of the code and call the methods of the corresponding model objects (which may encapsulate the dependencies and calls between the model objects themselves, but the one-to-many complexity here is not will be exposed to the outside), and also monitor the state changes of certain model objects and call the methods of the corresponding view objects (or re-render the Virtual DOM). Everything is bound.

For example, I usually use NervJS (model) + DermJS (view) + URLKit (route). NervJS and DermJS objects have their own event methods. In addition, a unified bus can also be passed in when the view/model object is initialized. event object.

When you write a UI component, of course you don’t want it to depend on a specific model. When you write a model component, you don’t want it to depend on a specific UI, so bindings such as one-to-many are in another place (specifically Business logic code) is completed. The view object and the model object do not need and should not know how many and which each other has, so it is impossible to "multiple Actions respectively correspond to the Store".

As for the problems of "a single file" and "constantly growing chaos", it is the same as configuring routing files. You can refer to relevant experience.

曾经蜡笔没有小新

In flux, if you need one action to correspond to multiple stores, it is actually easy to solve.
When registering the callback in the Store, you can just respond to this action, and you can also change the corresponding order through waitFor.

If you are worried about code confusion, you can write a separate constants file and define the name of the triggered event.

For example:

Click a button to trigger send事件,会更新两个Store分别是StoreAStoreB。可以写一个constants.js, first define the event name:

constants:

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

Then register callbacks in the two 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
    };
});

When the click event is triggered, the callback registered in Action中触发Disp的这个事件,就会顺序执行在StoreAStoreB is:)

洪涛

When this happens, what I usually think about is whether I can add a layer between them.

曾经蜡笔没有小新

If you haven’t seen it, or you have seen it but forgot, this is an article worth reading:

Patterns For Large-Scale JavaScript Application Architecture

Simply put, you need something "conventional" so that view and model do not need to depend on each other (whether it is a 1:1 dependency or a 1:N dependency).

You can also use simple event and observer patterns. If the business logic is complex, use mediator to complete communication and synchronization between modules.

PS: The ideal situation is that each of your modules only knows itself (what events are triggered, what events are listened to), and does not care about anything else, let alone the other party's instance, or the mediator's instance.

Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template
About us Disclaimer Sitemap
php.cn:Public welfare online PHP training,Help PHP learners grow quickly!