Comments 38
Интересно. Только мало. И про контроллеры ничего не сказано.
Да. Рассказ про контроллеры прямо таки интригует, учитывая, что:
documentcloud.github.io/backbone/#FAQ-tim-toady
Что лично я перевожу на русский как «Нет у нас никаких контроллеров».
Different implementations of the Model-View-Controller pattern tend to disagree about the definition of a controller. If it helps any, in Backbone, the View class can also be thought of as a kind of controller, dispatching events that originate from the UI, with the HTML template serving as the true view. We call it a View because it represents a logical chunk of UI, responsible for the contents of a single DOM element.
documentcloud.github.io/backbone/#FAQ-tim-toady
Что лично я перевожу на русский как «Нет у нас никаких контроллеров».
Если статья окажется интересной сообществу, напишу продолжение, с примерами
Сейчас бы с примерами сделали, а так читать довольно сложно сплошной текст.
Модели будут знать URL, куда слать GET, POST, PUT и DELETE
Также про PATCH могли бы рассказать, который сейчас поддерживается из коробки в Rails 4(думаю многие, кто работает с backbone&rails сталкивались с проблемой, когда backbone отправляет всю модель и приходилось городить свои огороды, чтобы отправить лишь часть атрибутов).
А можно поинтересоваться, зачем отправлять часть отрибутов модели?
Попробую ответить. Все атрибуты модели нужно отправлять на сервер только в случае её создания на стороне клиента. Все атрибуты отправлять от сервера клиенту может быть нужно только если логика приложения того требует. Во всех остальных случаях нужно передавать только названия и значения изменённых полей или полей, которые действительно нужны на клиентской стороне в этот момент.
Пробовали такой подход, но отказались, т.к. оптимизация сомнительная, а вот сложность кода возрастает (проверка на клиенте и формирование, потом проверка еще и на сервере). Говорю про связку backbone & asp mvc.
Что значит «нужно»? Какая выгода от этого?
«Нужно» не в смысле «все обязаны так делать». Выгода здесь двойная. Измеримая — в уменьшении трафика, в увеличении скорости обмена с сервисом, уменьшении времени на обработку запросов, уменьшение нагрузки на серверную часть. Выгода другого рода — мы не гоняем туда-сюда информацию, которая не используется в пункте назначения. Если я изменю поле «price» объекта «product», зачем мне слать серверу весь product, там может быть полей на килобайты, описания всякие, массив отзызов, да мало ли что ещё. Хватит отправить price и id и получить в ответ подтверждение, что запрос выполнен.
На вашем примере приведу аргументы, почему отказались от такого решения:
В итоге получим усложнение логики и экономию пары килобайт на запрос обновления. Довольно таки спорная оптимизация.
- Api ресурс объекта «product» не должен принимать связанные с ним сущности, такие как отзывы, комментарии, описания. Для этих элементов нужны свои ресурсы.
- Спорный момент, что обновление одного свойства на сервере быстрее (а в случае использования Entity Framework ORM для .net так разницы вообще не будет из за его особенностей работы. Для RoR принцип работы ORM'ок будет скорее всего такой же, но не возьмусь это точно утверждать). В итоге получим только усложнение кода, что не есть хорошо.
- Часто запросы на обновление таких объектов нивелируются по сравнению с количеством запросов на чтение. Т.е. лучше потратить время на оптимизацию этой операции.
- Для сущностей с действительно большими полями (сотни кб текста) лучше будет отправлять дельту изменений, хотя это то еще специфичное и на любителя решение.
В итоге получим усложнение логики и экономию пары килобайт на запрос обновления. Довольно таки спорная оптимизация.
ActiveRecord в RoR умеет отслеживать «dirty» поля, и сохраняет в базу только те поля, которые изменились. В итоге рельсе, в принципе, пофиг, всю модель мы ей отправляем, или только часть — код в контроллере одинаков, а ORM сама решает, какие поля ей сохранять.
Так что в частичной отправке полей всё же есть смысл.
Ну и, в конце концов, если вы редактируете статью на несколько кб, поменяв в ней только опечатку в title — действительно нет абсолютно никакого смысла, ни, тем более, профита!, в отправке ВСЕХ полей записи на сервер.
PS.:
Усложнение логики? Нее, не слышали.
Так что в частичной отправке полей всё же есть смысл.
Ну и, в конце концов, если вы редактируете статью на несколько кб, поменяв в ней только опечатку в title — действительно нет абсолютно никакого смысла, ни, тем более, профита!, в отправке ВСЕХ полей записи на сервер.
PS.:
# PATCH/PUT /posts/1
def update
if @post.update(post_params)
redirect_to @post, notice: 'Post was successfully updated.'
else
render action: 'edit'
end
end
Усложнение логики? Нее, не слышали.
Для сущностей с действительно большими полями (сотни кб текста) лучше будет отправлять дельту изменений, хотя это то еще специфичное и на любителя решение.
А это, значит, не костыли, да? :)
Ну да, еще электричество экономим и снижаем выбросы парниковых газов.
Но я скорее соглашусь с предыдущим комментарием: оптимизация сомнительная, а сложность кода возрастает.
Хотя, всяко бывает. Иногда это может быть важно.
И странно, что массив отзывов лежит в той же модели, что и продукт. Думаю, это ошибка.
Но я скорее соглашусь с предыдущим комментарием: оптимизация сомнительная, а сложность кода возрастает.
Хотя, всяко бывает. Иногда это может быть важно.
И странно, что массив отзывов лежит в той же модели, что и продукт. Думаю, это ошибка.
Я думаю, что этот индикатор работает так: в document.ready() вы сделали таймер и раз в 60 секунд запрашиваете адрес вроде /api/v1/kolichestvo_zakazov.
Кстати, а сам обмен Backbone.js как-то реализует? Или так же ручками таймер вешать, только модели заставлять синкаться?
Можно ручками таймер и синкать модель, можно воспользоваться плагинами и сделать обмен в real-time на основе websockets. Вариант с таймером на фоне остальных прелестей бекбона выглядит, конечно, деревянно, но тем не менее внутри обработчика таймера будет всего лишь одна строка: @model_name.fetch() — всё же лучше самописного кода, как мне кажется.
Ну, вообще говоря, там может быть простыня @model1.fetch(), @model2.fetch() и т. д.
@models.fetch()?
Вряд ли у Вас будет на одной странице такое множество РАЗНЫХ моделей, чтобы из их инициализации получилась простыня. Если Вы имеете ввиду, что у вас на странице множество экземпляров одного класса (например, 150 product'ов), то на этот случай Backbone умеет т.н. коллекции. Вы можете обновить сразу всю коллекцию: @products.fetch(). Вот так.
1. ЭТО очень кратко?
2. Если быть честным, кому вообще сдались ваши Рельсы? Это нынче тренд такой? Пэхапэшники — лошары?
*TROLL MODE OFF*
2. Если быть честным, кому вообще сдались ваши Рельсы? Это нынче тренд такой? Пэхапэшники — лошары?
*TROLL MODE OFF*
1. Это слишком кратко. Многое не написал, т.к. знаю, что тексты хорошо воспринимаются только до определённого количества слов :) Лучше написать продолжение.
2. Я буду с Вами честным: наши рельсы сдались очень многим. А кроме того, на месте Rails в этих примерах мог быть любой фреймворк (хоть и на PHP), приложение на котором реализует CRUD-интерфейс.
2. Я буду с Вами честным: наши рельсы сдались очень многим. А кроме того, на месте Rails в этих примерах мог быть любой фреймворк (хоть и на PHP), приложение на котором реализует CRUD-интерфейс.
1. Переосторожничали имхо :)
1. Поскольку вы же сами упомянули про то что о Backbone написаны горы туториалов (и это действительно так), я ожидал некого тезисного изложения, в максимально краткой форме: особенности, что хорошо, что плохо. Но это исключительно мои не оправдавшиеся ожидания.
2. Вы написали статью о фреймворке на языке JavaScript. Языке, по большей части, используемом для фронт-енд разработки. Более того, о фреймворке используемом не «аниматорами кнопок на jQuery», а людьми, большую часть времени занимающимися фронтендом. К чему вообще ваши пассажи о том кем им быть и знать или не знать рельсы (или любую другую backend технологию). Вариант «в глаза не видеть этот ваш серверсайд» — тоже возможен, учитывайте и его.
Ну и сказать по правде, если уж проводить параллели и точки соприкосновения с бэкендом — имхо делать это надо с максимальным покрытием аудитории. Ну или выдерживать полностью абстрактный уровень повествования. Вынесли бы в заголовок то что статья про Backbone+Rails, я бы и изначально не прицепился.
2. Вы написали статью о фреймворке на языке JavaScript. Языке, по большей части, используемом для фронт-енд разработки. Более того, о фреймворке используемом не «аниматорами кнопок на jQuery», а людьми, большую часть времени занимающимися фронтендом. К чему вообще ваши пассажи о том кем им быть и знать или не знать рельсы (или любую другую backend технологию). Вариант «в глаза не видеть этот ваш серверсайд» — тоже возможен, учитывайте и его.
Ну и сказать по правде, если уж проводить параллели и точки соприкосновения с бэкендом — имхо делать это надо с максимальным покрытием аудитории. Ну или выдерживать полностью абстрактный уровень повествования. Вынесли бы в заголовок то что статья про Backbone+Rails, я бы и изначально не прицепился.
Про рельсы тут чуть менее чем ничего. Собствеенно говоря даже про js практически ничего.
Интересно. Хочется больше.
Если мы говорим о серверном MVC, то там чаще всего уже есть модели.
И на клиентской стороне модели писать.
Как-то оно… не так.
Есть хорошее решение?
И на клиентской стороне модели писать.
Как-то оно… не так.
Есть хорошее решение?
А как по мне, то хорошо. Ещё лучше, конечно, их один раз написать и чтобы и на сервере, и на клиенте были, но не уверен, что такое даже с node.js можно малой кровью…
Ну почему же, описание модели — это, по сути, js код, загружаемый с сервера. Ничто не мешает нам генерировать его динамически. Единственная проблема — js-specific методы модели.
Я бы сказал — браузер-специфичные, или backbone,js специфичные, если угодно. Именно поэтому уточнил что не уверен что даже с node.js получится малой кровью связать.
А идея динамической генерации мне не нравится, даже если использовать какой-то вид кэширования, то есть генерировать не на каждый раз, а, скажем, при деплое. Мне миграций и копирования конфигов хватает.
А идея динамической генерации мне не нравится, даже если использовать какой-то вид кэширования, то есть генерировать не на каждый раз, а, скажем, при деплое. Мне миграций и копирования конфигов хватает.
UFO just landed and posted this here
Кое-чего не понятно без примеров. Откуда модели будут знать URL? Сколько кода получится?
И зачем писать на клиенте модель, контроллер, если нужно просто получить список товаров в корзине. Не представляю ситуацию, когда информацию о товаре нужно срочно обновить.
И зачем писать на клиенте модель, контроллер, если нужно просто получить список товаров в корзине. Не представляю ситуацию, когда информацию о товаре нужно срочно обновить.
А для чего данные упорядочивать на клиенте? Да еще и все?
Ну есть у меня на 200млн позиций БД под 160Гб размером, я все это должен разом выплюнуть клиенту? А там он пусть упорядочивает? Зачем?
И какой клиент это выдержит?
Ну есть у меня на 200млн позиций БД под 160Гб размером, я все это должен разом выплюнуть клиенту? А там он пусть упорядочивает? Зачем?
И какой клиент это выдержит?
А кто говорит про ВСЕ данные? Создается несколько моделей на клиенте и загружаются только необходимые в данный момент объекты.
Про «ВСЕ» данные говорит автор статьи
«Не надо ничего отправлять на сервер, получая ту же таблицу, только отфильтрованную, заново. Обьекты-то у вас уже есть, просто отфильтруйте коллекцию product'ов одной строкой кода на javascript. И да, они ещё и перерисуются сами»
Понимаете ли, фильтрация по цене текущей страницы и всего списка товаров (которые занимают надцать страниц) это две разные вещи.
В случае магазина первое вообще редко нужно. А для второго нужно загружать таки «все».
Т.е. в целом я понимаю, бывают случаи когда нужно фильтровать и сортировать данные уже находящиеся на клиенте полностью. Вот в этих случаях — да, дергать бекэнд как-то глупо. В остальном же… для более менее крупных объемов данных я бы оставил сортировку на бекэнде.
«Не надо ничего отправлять на сервер, получая ту же таблицу, только отфильтрованную, заново. Обьекты-то у вас уже есть, просто отфильтруйте коллекцию product'ов одной строкой кода на javascript. И да, они ещё и перерисуются сами»
Понимаете ли, фильтрация по цене текущей страницы и всего списка товаров (которые занимают надцать страниц) это две разные вещи.
В случае магазина первое вообще редко нужно. А для второго нужно загружать таки «все».
Т.е. в целом я понимаю, бывают случаи когда нужно фильтровать и сортировать данные уже находящиеся на клиенте полностью. Вот в этих случаях — да, дергать бекэнд как-то глупо. В остальном же… для более менее крупных объемов данных я бы оставил сортировку на бекэнде.
Sign up to leave a comment.
O Backbone.js очень просто и кратко для любителей MVC-фреймворков