Маршрутизация и события — backboneJS

Таким образом, все основные вопросы обычно заканчиваются многими правдоподобными ответами. В этом случае я считаю, что ваш второй пример является более каноническим/типичным магистральным шаблоном. Если оставить в стороне сложную проблему загрузки счетчиков и обновления после загрузки данных, упрощенный базовый шаблон в вашем маршрутизаторе будет таким:

routes: {
    'orders/view/:orderId' : 'viewOrder'
},

viewOrder: function (orderId) {
    //Use models to represent your data
    var orderModel = new Order({id: orderId});
    //models know how to fetch data for themselves given an ID
    orderModel.fetch();
    //Views should take model instances, not scalar model IDs
    var orderView = new OrderView({model: orderModel});
    orderView.render();
    //Exactly how you display the view in the DOM is up to you
    //document.body might be $('#main-container') or whatever
    $(document.body).html(orderView.el);
}

Я думаю, что это образец учебника. Опять же, вопрос о том, кто инициирует выборку данных и повторную визуализацию после их поступления, является сложным. Я думаю, что лучше всего, если представление знает, как отображать «загружаемую» версию самого себя до тех пор, пока модель не извлечет данные, а затем, когда модель запускает событие изменения после завершения выборки, представление повторно отображает себя с загруженными данными модели. Однако некоторые люди могут поместить эту логику в другое место. Эта статья о создании следующего звукового облака, я думаю, представляет многие очень хорошие «современные» магистральные шаблоны, в том числе то, как они обрабатывают невыбранные модели.

В общем, вы можете кодировать вещи с обратными вызовами или событиями по своему усмотрению. Тем не менее, хорошее эмпирическое правило — задать себе несколько вопросов:

1. Будет ли реагировать на это событие более чем одна независимая логическая часть работы?
2. Нужно ли отделять источник этого события от того, что происходит в ответ на него?

Если оба варианта «да», то события должны подойти. Если оба варианта «нет», то лучше подходит прямая логика функций. В случае «переход по этому URL-адресу запускает это представление», как правило, ответ на оба вопроса «нет», поэтому вы можете просто закодировать эту логику в методе обработчика маршрута маршрутизатора и покончить с этим.

Я бы использовал второй сценарий. Не вижу никаких преимуществ использования первого подхода. Это имело бы больше смысла таким образом (но все же спорно):

/* ... */
routes: {
    'orders/view/:orderId' : 'viewOrder'
},
viewOrder: function (orderId) {
    vent.trigger('order:show', orderId);
}
/* ... */
vent.on('order:show', function(orderId) {
    var viewOrderView = new ViewOrderView();
    viewOrderView.render();
});

var ViewOrderView = Backbone.View.extend({
    el: "#page",
    initialize: function (options) {
        this.orderId = options.orderId;
    },

    render: function () {
        var template = viewOrderTemplate({ 
            id: this.orderId 
        });
        this.$el.html(template);
        return this;
    }
});

Таким образом, по крайней мере, вы сможете инициировать действие маршрута без обновления URL-адреса. Но такого же эффекта можно добиться, вероятно, используя Backbone.router.viewOrder(1). События довольно мощные, но я бы не использовал их, если мне это действительно не нужно.