Patrones de diseño para una aplicación Rails 3.2 JS-heavy

Question

Estoy trabajando en una nueva aplicación de administración de compañía de 3.2 carriles que depende en gran medida de datos JSON (resultados de autocompletar, eventos de calendario, tareas, manipulación dinámica de formularios, etc.). El sistema de back-end ya es bastante sólido, por lo que estamos invirtiendo en la parte de la interfaz de usuario y queremos que sea más parecido a una aplicación web, reflejando el comportamiento de otras aplicaciones de "clientes gordos" como las de Google. Para lograr este objetivo, ¿cuál sería el mejor patrón de diseño: utilizando un framework MVC JS como Backbone.js, delegando así una buena parte de la manipulación de datos a la interfaz de usuario e interconectando con nuestra API api, o trabajando con JS remoto (es decir, js.erb templates), lo que permite un mayor uso del código de Ruby?

Ya usamos Backbone.js muy crudamente en algunas vistas, pero parece que el primer enfoque utiliza muchos recursos de desarrollador ya que JS es más difícil de codificar y tenemos la carga adicional de reflejar algún código de modelo en la interfaz de usuario , mientras que es mucho más sensible al usuario final. El último enfoque permite un código de vista más reducido a expensas del tiempo de respuesta y, en general, no se siente del todo bien, pero sin duda es más rápido de desarrollar y más flexible.

Teniendo en cuenta que somos un equipo pequeño con mucha experiencia en Rails y no tanto en JS/Coffeescript/Backbone.js y que tenemos un plazo cercano para cumplir, ¿qué enfoque elegirías? La razón por la que estoy perdiendo en este caso es que nuestra empresa se enorgullece de la calidad de nuestro código y la adhesión a los patrones de diseño modernos, así que no puedo evitar pensar que, a pesar de sus puntos fuertes, usar JS remota se siente como un ' mal atajo ', así que realmente agradecería la contribución de ustedes. Tal vez solo soy parcial.

Answer 1

Bueno, no puedo decidir por usted, eso depende principalmente de qué tan cerca esté la fecha límite, pero personalmente prefiero el enfoque Backbone.js.

Si tengo que discutir, puedo decir que tendrá un script JS estático y cacheable y solicitudes AJAX claras (solo JSON), mientras que con el otro enfoque tendrá descargas de scripts más pesados ​​y no guardables.

Pero, sobre todo, creo que la forma Backbone es la mejor manera de organizar y mantener su código.

1. Coffeescript es increíble y muy rápido de aprender. Simplifica mucho la sintaxis de JS y lo hace divertido. Vale la pena intentarlo. Aprendí en 30mn.

2. Backbone.js es increíble y rápido de aprender. El uso de este enfoque le permitirá confiar en los eventos, que es mucho más limpio de lo que podemos prescindir.

   Gracias a la canalización de activos, puede dividir su clase de vistas/modelos/enrutadores en archivos separados, lo cual es muy bueno.

   Gracias a CoffeeScript puede escribir sus objetos columna vertebral con una sintaxis muy limpia así:

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

   Con eso añado en mis proyectos un poco @module ayudante para organizar mis objetos en espacios de nombres.

Sin embargo, le tomará un tiempo encontrar la buena organización de archivos.

Puedes comenzar con gem rails-backbone y tener algunos generadores similares a los de los rails. No me gusta personalmente, pero creo que es un buen comienzo. Incluye una función Backbone.sync adaptada a los raíles.

Editar

Aquí algunos detalles sobre el @module ayudante. Incluyo esto en application.js.coffee (no se olvide de 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 

En mis archivos de clase:

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

(Tenga en cuenta que @ es el acceso directo para CoffeeScript this..)

El helper crea los objetos MyProject y MyProject.Model si es necesario (si es nulo) y ejecuta la función dada con this se unen a MyProject.Model. Para que pueda acceder a su modelo como el de espacio de nombres raíz (document):

m = new MyProject.Model.MyModel 

También puede imbricar el ayudante:

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

utilizo la jerarquía siguientes espacios de nombres

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