Недавно я столкнулся с несколькими ситуациями, когда у меня есть несколько представлений на странице, которые должны поддерживаться одной моделью. Таким образом, просто изменив модель, все соответствующие виды автоматически обновят свой внешний вид. Проблема в том, что для достижения этого АТМ мне нужно было бы написать код, который активно ищет эти модели. Иногда мне везет, и модель предоставляется мне через обработчик событий, но обычно это не так. Я ищу хороший способ иметь один экземпляр модели на странице за раз, а затем просто ссылаться на эту модель повсюду. Как люди обычно справляются с этой потребностью? Backbone-relational справляется с этим, сохраняя центральное хранилище с помощью lawnchair.js, и я слышал о людях, использующих единую глобальную коллекцию для ведения реестра всех моделей.
Backbone.js — Как обрабатывать несколько моделей с одинаковым идентификатором и типом? Или как избежать такой ситуации
Ответы (1)
Короткий ответ:
Одна модель, совместно используемая несколькими представлениями (которые вы могли бы назвать «дубликаты моделей»), на самом деле является вполне допустимым (и полезным) шаблоном Backbone; это вообще не проблема. Из того, что я могу сказать, проблема заключается в том, что эту модель трудно представить в нескольких представлениях, и поэтому я бы предложил вместо этого решить эту проблему.
Подробный ответ:
Проблема с передачей модели в несколько представлений заключается в том, что она по своей сути связывает представления вместе (чтобы предоставить эту общую модель каждому представлению, родительское представление также должно иметь эту модель, как и любые «промежуточные» представления). Теперь, как программистов, нас учат держать вещи как можно более инкапсулированными, поэтому поначалу связывание представлений может показаться «неправильным». Тем не менее, парные представления на самом деле желательны: главное правильно ограничить какие представления связаны.
@Shauna предложила для этого отличное эмпирическое правило: «представление заботится только о себе и создает своих детей». Если вы будете следовать этому правилу, связь между вашими представлениями не станет проблематичной, и вы сможете создавать гибкий, удобный для сопровождения код (намного более удобный, чем если бы вы использовали глобальные переменные, поскольку тогда вы бы действительно потерять инкапсуляцию).
В свете всего этого давайте рассмотрим быстрый пример. Допустим, у вас есть представления A, B и C, которые используют модель X, но вы строите A, B и C в совершенно разных местах кода (что затрудняет совместное использование X между ними).
1) Во-первых, я бы посмотрел, почему A, B и C строятся в таких разных местах, и посмотрел, нельзя ли сдвинуть их ближе друг к другу.
2) Если они должны быть построены так далеко друг от друга, я бы посмотрел, есть ли у них что-то общее, что я могу использовать; например, все ли эти точки имеют общий объект? Если это так, то, возможно, мы можем поставить X на этот объект, чтобы поделиться им со всеми нашими представлениями.
2) Если нет никакой связи ни в размещении кода, ни в общих переменных между A, B и C, тогда мне придется спросить: «Должен ли я вообще делить модель между ними?»
Скучная история об авторе:
Когда я впервые начал использовать Backbone, мне часто приходилось спорить с коллегами, потому что я хотел создать глобальные переменные, а они были категорически против этого. Я пытался объяснить им, что если бы я не мог использовать глобальные переменные, мне пришлось бы передавать модели из представления A в представление B, в представление C, в представление D, в представление E, тогда как эта модель действительно нужна только E. Такая трата!
За исключением того, что (как я потом узнал), я ошибался. Глобальные объекты — ужасная идея, по крайней мере, с точки зрения ремонтопригодности. Как только вы начнете их использовать, вы быстро не поймете, какой код на что влияет, потому что вы потеряете инкапсуляцию, которую обычно имеете между представлениями, использующими эту глобальную переменную. И если вы работаете над значительным проектом (т. е. таким, для которого стоит использовать Backbone), инкапсуляция — это единственный способ сохранить ваш код в порядке.
Много раз пользовавшись Backbone в промежутке между ними, я теперь твердо уверен, что правильный ответ — передать вашу модель вашему представлению по мере ее создания. Это может означать передачу моделей между промежуточными представлениями, которые не используют их напрямую, но это даст вам гораздо лучший, более удобный для сопровождения код, чем если бы вы передавали модели через глобальные переменные. Как бы неловко это ни казалось поначалу, передача моделей в представления при их создании является правильной практикой.
Как только вы поближе познакомитесь с Backbone, вы, вероятно, обнаружите, что вам очень редко нужно передавать модель через более чем одно промежуточное представление. Фактически, вы, вероятно, заметите, что всякий раз, когда вам приходится передавать модель между несколькими представлениями, вы обнаруживаете «запах кода», и что реальная проблема заключается в том, что ваш код нуждается в рефакторинге.
Но, как и во всем остальном на Stack Overflow, ваш пробег может отличаться ;-)
<li>
зависит от существования <ul>
или <ol>
, так что на самом деле не так уж много дополнительной связи при передаче параметра.
- person Shauna; 21.12.2012