Ответ 1
Так как Backbone.js не является основой как таковой, нет единого "правильного" способа сделать что-либо. Тем не менее, есть некоторые намеки на реализацию, которые помогут вам получить эту идею. Кроме того, есть некоторые общие проверенные временем методы организации кода, которые вы можете применить. Но я сначала объясню мнения.
представления
Представления в Backbone привязаны к определенным элементам DOM (для чего принадлежит свойство el).
Если, когда представление инициализировано, оно имеет атрибут el, а Backbone.js делает его свойством нового экземпляра представления. В противном случае он ищет атрибуты tagName, id и className, создает соответствующий объект DOM и в любом случае присваивает его свойству el для нового экземпляра представления. (Это объясняется в источнике.) Если даже нет tagName, то элемент <div> создается по умолчанию.
Итак, вы можете догадаться, почему TodoView и AppView используют разные подходы. Элемент #todoapp существует первоначально на странице в HTML, поэтому AppView может просто использовать его. Но когда создается представление для элемента todo, для него еще нет элемента DOM; поэтому разработчик имеет tagName, определенный в классе для Backbone, чтобы автоматически создать элемент списка. (Нетрудно сделать вручную метод initialize(), но Backbone экономит время, выполняя его для вас.)
Обычно представление относится к одной из двух категорий: представления для экземпляров модели и представления для коллекций. Магистраль не форсирует его, но предполагает, что он, вероятно, вам нужен: если вы создаете представление с параметрами collection или model, они становятся свойствами вновь созданного экземпляра представления, поэтому вы можете получить к ним доступ через view.collection или view.model. (Если вы, например, создаете экземпляр представления с опцией foo, он будет помещен в view.options.foo.)
Зависимости
Передовая практика
Это только мое мнение.
-
Меньшая зависимость лучше.
-
После шаблона MVC есть много преимуществ.
Обратите внимание, что терминология Backbone.js не соответствует классической MVC. Этот нормальный MVC!= Набор классов, и его определения немного отличаются. Это больше "идеал, который вы должны иметь в своем воображении" (цитируется Что такое MVC и каковы его преимущества?).
MVC | Backbone.js | What it does Controller | View (mostly) | Handles user interaction View | template rendered by a view | Displays the data Model | Model & Collection | Represents the data, handles data access
-
Слой модели обычно не должен зависеть от чего-либо. В MVC модель - это то, где вы получаете доступ к своим данным. Это не имеет никакого отношения, например, к представлению этих данных.
В Backbone модель может быть частью некоторой коллекции, но это не тяжелая зависимость (AFAIK, она просто помогает автоматически определять URL-адреса конечных точек API, соответствующих этой модели.)
-
В Backbone в коллекции может быть назначен соответствующий класс модели, но это также необязательно.
-
В Backbone маршрутизатор обычно зависит от представлений более высокого уровня (например, просмотров для целых страниц или разделов страницы), чтобы отображать их в ответ на изменение состояния приложения. Эти взгляды, в свою очередь, зависят от некоторых представлений более низкого уровня, таких как виджеты/разделы страниц. Эти взгляды могут зависеть от коллекций и других, даже более низкоуровневых представлений. Это, в свою очередь, может зависеть от конкретных экземпляров модели.
В качестве примера (стрелки обозначают "зависит от" типа отношения):
+-------------+ +---------------+ +------------+
State |MainRouter | Data: |ItemCollection | |ItemModel |
Control: |-------------| |---------------| |------------|
| | |/api/items +-->|/api/items/*|
| | | | | |
| | | | | |
+---+-+-------+ +---------------+ +------------+
| +----------------+ ^ ^
v v | |
+-------------+ +-------------+ | |
Page-level |AboutView | |AppView | | |
views: |-------------| |-------------| | |
| section | | section | | |
| role="main" | | role="main" | | |
+--+-+--------+ +--+-+-+------+ | |
| +---------------|-|-|----+ | |
| +----------+ | +----|---------+ | |
v v v v v | |
+--------------+ +--------------+ +---+-----------+ |
Widget |SidebarView | |HeaderView | |ItemListView | |
views: |--------------| |--------------| |---------------| |
| aside | | header | | ul | |
| | | | | | |
| | | | | | |
+--------------+ +--------------+ +-----------+---+ |
| |
v |
+--------+---+
|ItemAsLiView|
|------------|
| li |
| |
+------------+
Обратите внимание, что вы можете настроить несколько маршрутизаторов, и в этом случае все может выглядеть несколько иначе.
todos.js
В примере Todos разработчик решил, что экземпляры модели Todo должны зависеть от соответствующих экземпляров TodoView. Когда TodoView создается, он создает в соответствующем экземпляре модели свойство view и присваивает ему. Чтобы к нему можно было получить доступ some_todo_model.view. Однако следует отметить, что model.view используется только один раз в Todo метод модели clear(), чтобы удалить экземпляр представления, когда модель очищена.
Я думаю, что особая зависимость не нужна. Однако для такого небольшого приложения это может быть хорошо.
Я не смог найти какой-либо пример доступа к this.model.view в представлении, поэтому я не могу прокомментировать это.
См. также
- Ответы Жюльена Гимонта - почти все они касаются Backbone.js, я думаю, что это отличный источник информации.