RESTAdapter vs Localstorage. Почему я должен переключиться на RESTAdapter?

Question

Я работаю с Ember уже несколько месяцев. Наш проект должен был работать автономно, поэтому мы использовали App Cache и Ember Localstorage Adapter. Мне очень понравился этот подход. Мы загружаем все данные сразу с сервера, а затем используем его на всех маршрутах проекта.

В настоящее время мы должны создать панель администратора для нашего проекта. Не требуется работать в автономном режиме. Я думал, что могу попробовать RESTAdapter от Ember, так как это, по-видимому, самый популярный способ работы с данными.

Поначалу мне кажется, что это усложняет ситуацию.

Например (и я буду упрощать вещи, ради примера), у меня есть 2 сущности:

App.User = DS.Model.extend({ 
    firstName: DS.attr('string'), 
    lastName: DS.attr('string'), 
    phoneNumber: DS.attr('string'), 
    studies: DS.hasMany('study') 
}); 

App.Study = DS.Model.extend({ 
    name: DS.attr('string'), 
    description: DS.attr('string'), 
}); 

И в rotues

App.UsersRoute = Ember.Route.extend({ 
    model: function(){ 
     return this.store.find('user'); 
    } 
}); 

App.UserRoute = Ember.Route.extend({ 
    setupController: function (controller, model) { 
     var userId = model.get('id'); 
     this._super.apply(this, arguments); 
     this.store.find('user', userId).then(function (user) { 
      controller.set('user', user); 
     }); 
    } 
}); 

On The /users маршрут я показываю только основная информация пользователей. На маршруте /user я показываю его информацию и исследования, которым он назначен.

Это означает, что если пользователь перемещается от /users к /user маршруту с использованием transitionTo, то user шаблон будет получать user модель из хранилища данных в памяти. Тем не менее, пока нет studies и они не смогут их показать. В конце концов, мы должны скрыть studies модели с users.

Если /user маршрута осуществляется непосредственно из URL браузера или обновление страницы происходит, то сервер должен предоставить user модель с studies загруженную еще раз.

Итак, на стороне сервера мы должны реализовать два метода контроллера, которые должны возвращать что-то вроде этого.

/users маршрут:

`{ 
    "users":[{/*user1*/},{/*user2*/}], 
    "studies":[{/*study1*/}, {/*study2*/}, {/*study3*/}] 
}` 

/user маршрут -

{ 
    "user":{/*userdata*/}, 
    "studies":[/*and array of studies*/] 
} 

Учитывая, что мы не используем большие наборы данных. Предположительно до 20 пользователей и до 20 исследований, почему я не должен загружать их сразу и хранить их с помощью адаптера localstorage (чтобы сохранить данные в безопасности от обновления страницы) и использовать RESTAdapter?

Мне кажется, что с помощью RESTAdapter, мы должны писать гораздо больше кода на стороне сервера и самое главное опыт пользователей будут затронуты. Большую часть времени, когда будет доступен доступ к маршруту , произойдет отсрочка на несколько секунд, в то время как запрос отправит его обратно на сервер и обратно.

Пожалуйста, поделитесь своим мнением. Зачем использовать RESTAdapter, если нет больших наборов данных? Насколько большой должен быть набор данных для принудительного использования RESTAdapter? Существуют ли какие-либо другие преимущества перед локальным хранилищем?

Answer 1

Вы всегда можете push everything вам нужно в магазин (с использованием push, pushMany или pushPayload), в этом случае у вас нет большого количества данных, поэтому его не большое дело, но вам все равно придется принести это по крайней мере один сервер, который является вашим источником правды.

Но поскольку это панель администратора, я думаю, вы не только отображаете данные, но также обновляете и, вероятно, удаляете, поэтому вам придется по-прежнему внедрять методы для обработки на стороне сервера, а REST - это стандартная подход, чтобы сделать это, но ember не заставляет вас использовать его, если вы хотите, вы можете alwasy делать $.post (не рекомендуется).

Вам также не нужно загружать сторону все, вы можете определить ваш relationshipt async

studies: DS.hasMany('study', {async:true}) 

И тогда уголек будет первым ударил /user, а затем /studies/{id} для каждого исследования, связанного с этим пользователем.

Для получения дополнительной информации см. the guide.