Пользовательские маршруты отдыха Backbone.js

Question

Я новичок в магистрали и тестирую свое первое приложение после прохождения нескольких учебных приложений.

мне было интересно, что это лучший способ для выполнения следующих

На внутреннем интерфейсе (рельсов)

У меня есть название модели бизнес, Это сложная модель с большим количеством атрибутов, он имеет связанный адрес (has_one :address), и у него есть аватар, а другой профиль - яма и многое другое.

Из моего внешнего интерфейса я хочу иметь возможность получать и обновлять определенные части бизнес-профиля. Предположим, что я хочу только получить basic_info, который включает имя, категорию и адрес, чем я хочу, чтобы иметь возможность обновлять изображение профиля и аватар.

То, что я видел в позвоночнике, что модель имеет методы сохранения, обновления, принеси, уничтожить

Что делать, если я хочу, чтобы другие методы, такие как fetch_basic_info, fetch_profile_picture, update_profile_picture? и против них я хочу, чтобы соответствующие представления были уведомлены соответствующим образом.

Вот что я придумал

Допустим, я хочу получать основную информацию

• добавить функцию fetch_basci_info к магистральной модели

  • внутри этой функции Написать пользовательский запрос ajax с использованием $.ajax на сервер
  • вручную активировать событие "basicinfo:fetched"

• внутри моей функции маршрутизатора

  • создать модель объекта
  • создать новый вид позволяет говорить BasicInfoView и передать его модель объекта
  • внутри зрения связать даже модели позволяет скажем model.bind('basicinfo:fetched', this.render)
  • , когда маршрутизатор инициализируется вызовом model.fetch_basic_info (в маршрутизаторе init)

Так маршрутизатор называется он создает вид связывает пользовательское событие и вызывает model.fetch_basic_info() запрос отправляется ответ сервера возвращается (я называю установить вручную, чтобы установить атрибуты скелетной модели здесь). После этого пользовательское событие события запускается, уведомление отображается и отображается

Это мое первое реальное базовое приложение, поэтому, если я делаю что-то действительно, не останавливай меня.

Что вы думаете об этом.

Благодарим вас за чтение и feedbcak.

Answer 1

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

По правде говоря, выборка только изображения профиля использует примерно те же ресурсы, что и выбор 50-100 полей. Да, немного больше данных, но учитывая, что 90% работы, латентности, ресурсов и времени ожидания в сетевом соединении происходит от установления соединения, которое вы на самом деле не сохраняете.

Plus на конце базы данных,

select * from businesses where id=123

использует только чуть-чуть больше, чем

select profilepic from businesses where id=123

поскольку самую трудную часть работы устанавливает соединение с базой данных и найти правильную строку. После этого его немного больше данных - добавление 50 дополнительных столбцов окажет незаметное влияние на производительность.

Единственный раз, когда это падает, если ваша модель/таблица содержит сотни или тысячи атрибутов. В этом случае решение состоит в том, чтобы разбить вашу модель на подмодели. И обрабатывайте их индивидуально через REST. Но они должны быть типами бизнес-логики. Например, Business содержит Address, Employee, ShareStructure.

Я сам был преждевременным оптимизатором ... «Не нужно возвращать 10 столбцов, когда мне нужен только 1 столбец». Но если попытаться написать API-интерфейсы веб-сервисов для каждого подмножества данных в своих различных комбинациях, которые вам когда-либо понадобится, ваш API будет практически непригодным для использования и недостижимым. Вы также никогда не добьетесь какой-либо работы.

Допустим, вы хотели, чтобы получить фотографию Cocacola прочь API facebook, вы просто звоните:

https://graph.facebook.com/cocacola

и получить Picture собственности. Кого волнует, если вам не нужны остальные данные? Он сохраняет все просто, спокойно и легко.

Answer 2

Моя первая мысль заключается в том, что вы будете тиражировать много функций, уже предоставляемых магистральной сетью. Я не вижу причин, по которым вам нужно точно повторить вашу бизнес-модель на стороне клиента. Почему бы не разбить свою основную информацию, профиль и т. Д. На отдельные модели Backbone и применять их к вашим представлениям по мере необходимости.