Шаблоны проектирования для приложения Rails 3.2 JS-heavy - PullRequest
Новая
       17

Шаблоны проектирования для приложения Rails 3.2 JS-heavy

6 голосов
/ 20 февраля 2012

Я работаю над новым приложением для управления компанией rails 3.2, которое в значительной степени опирается на данные JSON (результаты автозаполнения, события календаря, задачи, динамические манипуляции с формами и т. Д.). Бэкэнд-система уже достаточно прочная, поэтому мы вкладываем средства в пользовательский интерфейс и хотим сделать ее более похожей на веб-приложение, отражая поведение других приложений с «толстым клиентом», таких как Google. Для достижения этой цели, что было бы лучшим шаблоном проектирования: использование JS-инфраструктуры MVC, такой как Backbone.js, таким образом делегируя значительную часть манипулирования данными пользовательскому интерфейсу и взаимодействуя с нашим JSON API, или работая с удаленным JS (т.е. шаблоны js.erb), что позволяет более широко использовать код Ruby?

В некоторых представлениях мы уже очень грубо используем Backbone.js, но кажется, что в первом подходе используется много ресурсов для разработчиков, поскольку JS сложнее в кодировании, и у нас есть дополнительное бремя зеркалирования некоторого кода модели в пользовательском интерфейсе, будучи намного более отзывчивым к конечному пользователю. Последний подход позволяет использовать более компактный код View за счет времени отклика и, в целом, выглядит не совсем корректно, но он, безусловно, быстрее развивается и более гибок.

Учитывая, что мы небольшая команда с большим опытом работы с Rails и не так много в JS / Coffeescript / Backbone.js, и у нас есть крайний срок выполнения, какой подход вы бы выбрали? Причина, по которой я теряюсь в этом, заключается в том, что наша компания гордится качеством нашего кода и приверженностью современным шаблонам проектирования, поэтому я не могу не думать, что, несмотря на свои сильные стороны, использование удаленного JS выглядит как ' плохой ярлык », поэтому я был бы очень признателен, если бы вы, ребята, внесли свой вклад. Может быть, я просто предвзятый.

1 Ответ

2 голосов
/ 16 марта 2012

Ну, я не могу решить для вас, это зависит, главным образом, от того, насколько близок крайний срок, но я лично предпочитаю подход Backbone.js.

Если я поспорю, я могу сказать, что у вас будетстатические и кешируемые JS-скрипты и легкие AJAX-запросы (только JSON), в то время как при использовании другого подхода вы будете загружать более тяжелые и не кешируемые скрипты.

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

  1. Coffeescript - это круто и очень быстро для изучения.Это значительно упрощает синтаксис JS и делает его интересным.Это стоит попробовать.Учился в 30 мин.

  2. Backbone.js - это круто и быстро для изучения.Использование этого подхода позволит вам полагаться на события, которые намного более чисты, чем то, без чего мы не можем обойтись.

    Благодаря конвейеру ресурсов вы можете разделить свой класс представлений / моделей / маршрутизаторов на отдельные файлы, которыеэто очень приятно.

    Благодаря coffeescript вы можете написать свои базовые объекты с очень чистым синтаксисом, подобным этому: 

    class @MyView extends Backbone.View
  events:
    'click obj': 'handler'
  [...]

    С этим я добавляю в свои проекты небольшой @module помощник дляорганизовать мои объекты в пространства имен.

Однако вам потребуется некоторое время, чтобы найти правильную организацию файлов.

Вы можете начать с gem rails-backbone и иметь несколько генераторовпохожи на рельсы.Мне не нравится это лично, но я думаю, что это хорошее начало.Он включает в себя функцию Backbone.sync, адаптированную к рельсам.

Edit

Вот некоторые подробности о помощнике @module.Я включаю это в application.js.coffee (не забудьте require_self): 

@module = (names, fn) ->
  names = names.split '.' if typeof names is 'string'
  space = @[names.shift()] ||= {}
  space.module ||= @module
  if names.length
    space.module names, fn
  else
    fn.call space

В моих файлах классов: 

@module 'MyProject.Model', ->
  class @MyModel extends Backbone.Model
    [...]

(Обратите внимание, что @ - это coffeescriptярлык для this..)

Помощник создает объекты MyProject и MyProject.Model при необходимости (если ноль) и выполняет данную функцию с this привязкой к MyProject.Model.Таким образом, вы можете получить доступ к своей модели, например, из корневого пространства имен (document): 

m = new MyProject.Model.MyModel

Вы также можете использовать помощника: 

@module 'MyProject', ->
  @module 'Model', ->
    [...]

Я использую следующую иерархию пространств имен 

MyProject
  Model
  View
  Router
  Runtime (to store all runtimes objects and don't pollute the root namespace, easier for debug)
...